Dynamic Annotation List Service

[azaroth42]

Requested Feature: A service profile that allows a manifest to record dynamically generated annotation lists, or lists of lists. The service could determine the user, and present further annotations that they have access to but are not part of the "official" facsimile.

The response would be an sc:AnnotationList, as currently defined, or like "otherResources" in the canvas.

Questions remain as to:
Should there be one service per canvas, and if so does the current spec not suffice?
Should there be one service per Manifest, and if so:
Should it be called once per Canvas (and if so, what's wrong with current spec beyond having to repeat the same field per Canvas?)
Should it be called once per Manifest, with the response containing annotations for all of the Canvases?
Are there additional parameters or requirements for the call that need to be added?

Notes:

• Agreed for further discussion

Action:

• Discuss on IIIF-Discuss

Proposal:

service: {
  "@id" : "http://.../service?canvas=asdf", 
  "profile" : "http://.../annotationListService"
} 

[azaroth42]

Need further experience with solutions, such as:

• Auth.
• Transient resources (such as Layers) rather than static/permanent ones
• Dynamic, overlapping sets (eg AnnoList may appear in multiple layers)

ACTION on Yale and Stanford to implement a Layer based solution and see whether this solves the use case requirements. Then reassess from a position of understanding.

[azaroth42]

As of 6/25, (at least) Yale, Stanford, Harvard and Wellcome are interested in seeing this happen. Proposal was to come up with a strategy using a service on iiif-discuss, implement at the different institutions and see how well it works.

[azaroth42]

Propose that this, like audience, is just search, and should be discussed in that context.

[azaroth42]

Decided it is just search.

[azaroth42]

So we broke it...

[aeschylus]

Agreed that it is best left search-based. As an outcome of the design meeting last week, we will be implementing a layer-based interface in Mirador for transcription next week, in which the user "opens" a "layer" for viewing, and advancing to the next canvas keeps the associated list from that layer displayed. To clarify none of this is "dynamic" in the search sense, but we'll report back here as to limitations we bump up against using layers and annotation lists.

One conceptual problem we encountered was how to associate a list with a page. The layers field can have a list of lists contained in that layer, but one must then filter the contents of those lists to extract the annotations pertaining to different parts of the manifest. This requires dereferencing and parsing all lists before any summary of their association can be rendered for the user (such as an indication of which canvases have annotations). An approach we developed, which may be wrong, is to list annotation lists on each canvas and use the "within" property to point to the associated layer. This makes it possible to populate the interface without dereferencing anything until its full content is needed.

I'm not sure how which of the dynamic list services would best mitigate this summary problem of needing to know what exists at an overview level.

[azaroth42]

@aeschylus Canvas -> AnnotationList -> Layer, like in the example in the docs? 😉
See: http://iiif.io/api/presentation/2.0/#layers

[azaroth42]

I think this is now closed by search. @mikeapp?

[mikeapp]

I agree, we can close.