We have a group of students building a rich annotation tool for IIIF images as they are annotated on Canvases. Any Canvas URI could be passed to the tool (standalone or embedded) and the Canvas would be displayed with existing annotations. New annotations will be saved in a new list referencing, but not modifying the remote resource.
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.
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."
The third-party solution is a hacky mess. I would make a service that resolves Manifests and returns the Canvas so get://tool.org/fetchcanvas/[sequence#]/[canvas#]?uri=MANIFEST_URI would return a Canvas. This should work, since sequences and canvases are both @list containers, meaning the order matters. However, it is a fragile link and is useless for someone who just knows the Canvas URI, which is not required to refer to an aggregating Manifest.
The other option would be that all of these types of tools would require an intermediate step, where the Manifest would be loaded and then the Canvas is selected from within the tool. This is redundant for users who have already browsed to a page of interest at a repository, challenging or unwieldy for any Manifest with many Canvases, and insincere for any interface intending on providing access to only one Canvas and not its siblings.
Additional Background
There is a guarantee that the Canvas will always be found in the Sequence in the Manifest. However, without stronger encouragement that the MAY at least becomes a SHOULD, the Annotation Tool cannot reliably work like Mirador does, having a URI in the request to launch easily. For example, right now some Mirador installs will accept http://demo.org/mirador?uri=http://www.e-codices.unifr.ch/metadata/iiif/bge-cl0015/manifest.json (or a URL-encoded equivalent) and automatically load "Genève, Bibliothèque de Genève, Comites Latentes 15" without fuss. This only works because the Manifest URI will always point to a resolvable dereferencable Manifest.
Description
We have a group of students building a rich annotation tool for IIIF images as they are annotated on Canvases. Any Canvas URI could be passed to the tool (standalone or embedded) and the Canvas would be displayed with existing annotations. New annotations will be saved in a new list referencing, but not modifying the remote resource.
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.
related stories: #54 #55 #56
Proposed Solutions
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."
The third-party solution is a hacky mess. I would make a service that resolves Manifests and returns the Canvas so
get://tool.org/fetchcanvas/[sequence#]/[canvas#]?uri=MANIFEST_URIwould return a Canvas. This should work, sincesequencesandcanvasesare both@listcontainers, meaning the order matters. However, it is a fragile link and is useless for someone who just knows the Canvas URI, which is not required to refer to an aggregating Manifest.The other option would be that all of these types of tools would require an intermediate step, where the Manifest would be loaded and then the Canvas is selected from within the tool. This is redundant for users who have already browsed to a page of interest at a repository, challenging or unwieldy for any Manifest with many Canvases, and insincere for any interface intending on providing access to only one Canvas and not its siblings.
Additional Background
There is a guarantee that the Canvas will always be found in the Sequence in the Manifest. However, without stronger encouragement that the MAY at least becomes a SHOULD, the Annotation Tool cannot reliably work like Mirador does, having a URI in the request to launch easily. For example, right now some Mirador installs will accept
http://demo.org/mirador?uri=http://www.e-codices.unifr.ch/metadata/iiif/bge-cl0015/manifest.json(or a URL-encoded equivalent) and automatically load "Genève, Bibliothèque de Genève, Comites Latentes 15" without fuss. This only works because the Manifest URI will always point to a resolvable dereferencable Manifest.