This project will soon be part of the Hyperion Framework and APIs finalised. The aim of this library was to standardise both the IIIF presentation 2 and 3 specifications and provide a single layer for accessing data from them. As an experiment it was a success. However, the practicalities of supporting 2 presentation versions, and more when further versions are released is unrealistic.
Where the Hyperion Framework is different is that it will always chase the specification. It is designed to internally work with latest Presentation version, and all IIIF resources requested by it will be upgraded on the fly to the latest version. It's also grounded in strong types, although does not require types to be used by consumers of the framework. This provides a better foundation for writing libraries and tools on top of the IIIF specifications, and is a consolidation of various experiments.
The original architecture and readme can still be found below. You can find some more experiments in the pull requests.
Demo | Concepts | API Proposal | Selector API | IIIF Spec progress | Contributing
Pull requests + issues are welcomed to discuss and improve this proposal.
IIIF Redux is a single source of truth for IIIF resources, split into 3 distinct packages:
- IIIF Redux - the "to the spec" implementation, storing and normalizing collections, manifests and canvases.
- IIIF Redux Viewer - more state, actions and selectors for building a viewer experience
- IIIF Redux Creator - new set of actions for drafting and editing IIIF resources, and hook-able middleware for saving, for creating editor UIs for IIIF resources.
- IIIF Service plugins - Community sourced set of plugins for understanding and presenting different services on IIIF resources.
- IIIF GraphQL - built using the selector library, an interface to IIIF endpoints using GraphQL.
- IIIF Redux AV - Redux state in the temporal dimension, with extensions focused on displaying AV content.
- IIIF Presentation Upgrade - Presentation 2 to 3 converter, Presentation 2 or 3 normalization, fixing and validation.
- Concepts - Primer for the structure of the API
- API Proposal - Proposal for how the whole API will function
- Selector API - How the selector API works currently
- IIIF Spec progress - Check list of all IIIF Resource selectors
- Contributing - Contributing guidelines
For libraries that deal with interoperable data its important to have smoke tests that can be run over
large sets of manifests. These tests would have to be expect(blah).toExist() or expect(blah.length).not.toEqual(0) type
tests that SHOULD pass for all manifests.
In addition unit tests of the units that make up the library (selectors, reducers, actions).
Finally running Interoperable Manifesto library through Manifesto's tests too would work to ensure parity.
This project is currently firmly in the planning and prototyping stages at the moment. Any contributions in the form of pull requests or issues for discussion are welcome.
