search

IIIF / iiif-stories

Community repository for documenting stories and use cases related to uses of the International Image Interoperability Framework.
21 stars 0 forks source link

As a digital object repository developer, I want to dynamically create object presentation manifests with SPARQL #47

Closed christopher-johnson closed 7 years ago

christopher-johnson commented 8 years ago

I am implementing a Fedora 4 repository for manuscripts and museum objects with a data model that will be based on the Presentation 2.0 API. The objective is that having the data structured similarly will facilitate serialization of presentation objects directly from a SPARQL query. For example, a query could construct a presentation with arbitrary criteria, "where <range r> sc:hasCanvases ?canvases", so that only a specific part of the manuscript is presented.

The functional complexity exists in developing SPARQL query methods that can iterate through a JSON-LD list RDF structure. For reference, the RDF representation of JSON-LD list for a IIIF sequence looks like this: <> sc:hasCanvases :c002 . :c002 rdf:first http://localhost:8080/fcrepo/rest/edition/00027/canvas/c001 . :c002 rdf:rest :c005 . :c005 rdf:first http://localhost:8080/fcrepo/rest/edition/00027/canvas/c002 . :c005 rdf:rest _:c008 . ... So any JSON-LD list is basically a chain of RDF blank nodes. I am not sure that there is anything that can be done from the IIIF perspective, but thinking forward, interoperability = embracing linked data semantics. Simply parsing the manifest as a normal JSON, seems to be the current client implementation approach. This may work, but certainly does not provide the flexibility and interoperability that the API is trying to achieve.

I have actually been able to construct a multiple canvas ordered IIIF manifest sequence from a SPARQL query. The output format of the manifest can be viewed here . So, I believe that this story is indeed possible. I see the concrete implementation of this as a "manifest generator" service that assembles, executes and delivers the manifest based on variable criteria.

azaroth42 commented 7 years ago

Implementation details only, no actual actionable story. Propose close.

christopher-johnson commented 7 years ago

From my perspective, this story has been actionable and productive. I have achieved a prototype and am now heavily into developing the potential of the Fedora API-X for extending image related services and discovery via HATEOAS and RDF service registries.

Once I have finished the last feature of the prototype (a TIFF to JP2 encoder using API-X), I will announce the docker composition on the IIIF mailing list.

Thank you for your assistance in clarifying the JSON-LD questions that have arisen in developing the manifest-service. You can close this story as those context issues have (more or less) been resolved and do not block me in any way.

As a reference, here is a link to my presentation in November at SWIB16 (where I met Simeon Warner)