This currently works for Manifest-at-a-time projects, since the Manifest URI is always dereferencable. However, most repositories do not supply a Canvas object at the Canvas URI, which means that single pages of transcription, while valid and interoperable with any IIIF exhibit application cannot be entered reliably without more complex APIs that instruct the transcription application on how to find the correct Canvas from the entire Manifest.
Variation(s)
This is important in mapping, transcription, marginalia annotation, entity (personal name, geographic location, etc.) annotation and many others where the Canvas is interesting, but the Manifest is excessive or too imprecise to be useful. In works in progress or crowd-sourced efforts where some Canvases are included, but others are not intended for release or comment, this would be helpful.
related stories: #53 #54 #56
Proposed Solutions
The desired solution would be for the Canvas object to be reliably available at its URI. If I knew I could get p1 at http://example.org/iiif/book1/canvas/p1 my button could simply direct to a tool at http://tool.org/transcribatron?uri=http://example.org/iiif/book1/canvas/p1. There may be an API for changing the location of the saved annotations or the attributions attached, but it could be as simple as that.
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
Beyond just a button, the tool used could have a default interface allowing users to simply input a Canvas URI and begin transcribing any hosted resource. It would be a small preprocess to allow linking to any hosted image (Flickr, Google, etc) and to build a Canvas around it, devoid of any Manifest reference. A service would be easy to set up that would create a URI for the new annotationList that is needed to hold these annotations and return its location to the referrer, so any repository that wants access to the work done on their resources would not need to query the graph for their identifiers, but could just keep internal track of the lists' URIs on their own Canvases.
We've got legs here, but it all relies on the Canvas URI being a real thing and not just an identifier.
Description
This currently works for Manifest-at-a-time projects, since the Manifest URI is always dereferencable. However, most repositories do not supply a Canvas object at the Canvas URI, which means that single pages of transcription, while valid and interoperable with any IIIF exhibit application cannot be entered reliably without more complex APIs that instruct the transcription application on how to find the correct Canvas from the entire Manifest.
Variation(s)
This is important in mapping, transcription, marginalia annotation, entity (personal name, geographic location, etc.) annotation and many others where the Canvas is interesting, but the Manifest is excessive or too imprecise to be useful. In works in progress or crowd-sourced efforts where some Canvases are included, but others are not intended for release or comment, this would be helpful.
related stories: #53 #54 #56
Proposed Solutions
The desired solution would be for the Canvas object to be reliably available at its URI. If I knew I could get
p1athttp://example.org/iiif/book1/canvas/p1my button could simply direct to a tool athttp://tool.org/transcribatron?uri=http://example.org/iiif/book1/canvas/p1. There may be an API for changing the location of the saved annotations or the attributions attached, but it could be as simple as that.The standard already has an opinion about dereferencable Canvas 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
Beyond just a button, the tool used could have a default interface allowing users to simply input a Canvas URI and begin transcribing any hosted resource. It would be a small preprocess to allow linking to any hosted image (Flickr, Google, etc) and to build a Canvas around it, devoid of any Manifest reference. A service would be easy to set up that would create a URI for the new annotationList that is needed to hold these annotations and return its location to the referrer, so any repository that wants access to the work done on their resources would not need to query the graph for their identifiers, but could just keep internal track of the lists' URIs on their own Canvases.
We've got legs here, but it all relies on the Canvas URI being a real thing and not just an identifier.