Specification Draft:
- This service returns a specification conformant JSON IIIF Manifest from a web application query request.
- The service response will return either:
- a static Manifest resource from a known URI e.g.
<http://m.blumenbach.org/static/manifest_601.json>
OR- a query generated object based on an a Fedora RDF resource identifier e.g.
<http://f.blumenbach.org/fcrepo/rest/<edition>/{id}/manifest>
- The query request is a parameterized API call
- (e.g.
http://blumenbach.org/<datasource>?subject=<subject>&template=manifest
) - The service routes the template parameter to a datasource with a matching query template.
- template options: [manifest, canvas, range, layer]
- Only one
<resource>
is allowed for the SPARQL CONSTRUCT query. - The service then with an XHR calls the SPARQL endpoint with an Accept: JSON-LD header and POSTs the query.
- The endpoint JSON-LD response is transformed by the service in a multi-step process:
The de-normalization involves parsing the object, removing blank node @id references, replacing prefixed elements with aliases, removing rdf:first and rdf:rest elements, and serializing and validating the output as JSON.
- The serialized JSON output response should conform exactly to the IIIF standard that dictates the expectations of the client viewer. typical manifest example
- The complexity of the "de-normalization" of JSON-LD lists.
- For large manifests, SPARQL CONSTRUCT is a very expensive query operation.
- Use the Linked Data Fragments Client SPARQL iterator to traverse "typed" RDF sequences and assemble them as javascript arrays:
- example chaining
?subject -> ?object -> ?subject
and pushing the ?objects. - the array is then framed into JSON according to the "type" of the sequence.
- list types include: sequences (ranges), canvases, images, lists
<img src="https://github.com/blumenbach/iiif-manifest-service/blob/master/spec/objects-all.png"alt="" />