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

I would like to display an image annotation on a website #54

Open cubap opened 8 years ago

cubap commented 8 years ago

Description

I would like to use a component that accepts a SharedCanvas ContentAnnotation as a parameter and renders the selector for simple viewing. It would be great to also view details and edit the annotation, but this is already possible once the Canvas problem is resolved.

Variation(s)

This is could be used in mapping, transcription, marginalia annotation, entity (personal name, geographic location, etc.) annotation rendering and many others where the Canvas clip is interesting.

related stories: #53 #55 #56

Proposed Solutions

The root of the problem is that if an Annotation has a property like "on": "http://dms-data.stanford.edu/data/manifests/BnF/jr903ng8662/canvas/canvas-7#xywh=339,239,3325,272" any app could easily draw it if the full Manifest was available in memory. Since in this case the Canvas is not available at http://dms-data.stanford.edu/data/manifests/BnF/jr903ng8662/canvas/canvas-7 the height/width and imageAnnotation cannot be known to render the xywh= box for viewing. The only way to workaround it at this point is to hope the URI pattern recommendations are followed, guess what Manifest this Canvas may be part of, and search for it.

The standard already has an opinion about dereferencable Canvas URIs:

Canvases MUST be identified by a URI and it must be an HTTP(s) URI. … Canvases MAY be dereferenced separately from the manifest via their URIs

If the MAY becomes a SHOULD or if institutions are just better at providing access to their Canvas objects, this will "just work."

Additional Background

Choosing not to provide Canvas objects at their URIs means no Annotation can find its parent at all—the Canvas MUST be known first.

cubap commented 8 years ago

This does not jive with the concept of Linked Data, for me. If an Annotation is capable of telling me exactly where it is pointing, and that pointed to resource is open and available, and that resource would have been knowable through another path, but is not dereferencable in the selector I have been given, then either the selector or the access to the resource has erred.

I would rather encounter a more reliable pattern such as [manifestURI]/[sequenceIndex]/[canvasIndex]#xywh=0,0,0,0 if the Canvas will not be available than just the Canvas URI followed by a selector.

cubap commented 8 years ago

Sounding Tennyson and Tradamus use this right now and accidentally work. This will be a problem as usage grows, so MAY is a MUST for us. st

aeschylus commented 8 years ago

I second the "MAY" SHOULD be a "MUST" on this front. There are legitimate concerns about implementors having the flexibility they need, but the linked data aspect of this simply will never work unless there is a link back to the reference. "Within" is a valid field on every node type (including canvases and annotations), so that is another, more explicit convention that could be used to achieve this, but it is also optional.

dnoneill commented 4 years ago

Not sure if this is what you are looking for but this library might work: https://ncsu-libraries.github.io/iiif-annotation/tag-builder/#/