search

ProjectMirador / mirador

An open-source, web-based 'multi-up' viewer that supports zoom-pan-rotate functionality, ability to display/compare simple images, and images with annotations.
https://projectmirador.org
Apache License 2.0
548 stars 258 forks source link

Dereference Layers to which AnnotationLists belong #589

Open mikeapp opened 9 years ago

mikeapp commented 9 years ago

When AnnotationLists are loaded, dereference the Layers they are a member of (via within). This will enable a display of the the Layer label/description in the "Text" side panel.

aeschylus commented 9 years ago

I'm afraid we've gotten a bit ahead of ourselves, but we're making due. I envy Tom, who can "look ahead" to having all preliminary questions resolved. We know a lot more about this now. Look forward to a post to the list with more detail.

The current work on transcription has been based on a dynamic store. We've been using this as a proxy for a persistent "layer" and "list" across all canvases. We are looking for any otherContent lists and will displaying them in the UI, but right now we have no fixture manifests with any otherContent using a within field. To develop toward this issue in the way originally intended, we need two kinds of supporting resources:

  1. A manifest with otherContent fields on its canvases. The list referenced must have a "within" field defined on them, preferably in the metadata embedded in the manifest's otherContent array entry, as described by @azaroth42. The client can then build up a list of layers from the lists, as described above by @mikeapp. Mike has created a suite of layers and annotation lists pointing to those layers, but as yet, we have no manifests that point to those layers. We could easily create one ad hoc, but it would not support the development of this feature because of the following requirement.
  2. Secondly, and this is more vague, there must be a way to save an annotation to a specific list, so that it may be retrieved by reloading the same list previously referenced from the manifest. Judging by the nature of annotations, it seems this would have to involve creating the annotation with a service, and then the list itself would need to be edited to point to that annotation, since one annotation can belong to multiple lists. In general, this implies some coöperation between the dynamic annotation service and the server hosting the manifest lists provided in the manifest.

What is this relationship? Right now the dynamic annotation endpoint is not a service in IIIF terms; it's just a mirage created by a particular configuration of Mirador that makes it send a search request on every page turn. What is the IIIF-sanctioned equivalent of this behaviour? How can a manifest instruct Mirador to do this (or should it)? How can a client retrieve a list from otherContent and then persist an addition to that list?

As far as we know, no such server exists to support this activity, and the specification does not discuss this kind of exchange between lists and annotations. CRUD via REST has not been hashed out for manifests, and I haven't heard it discussed for annotation lists. At best it can be hacked together and the UI can be as decoupled as possible from the underlying shim of guesses. This is what we have done, treating the search response on the page turn as the authoritative "list" (which ought to come form otherContent, but there is no way to connect the two because of requirement 2, above, not being met by any known software) that is assumed to be "within" its own layer with the "label" and "description" passed in as configuration options for Mirador.

azaroth42 commented 9 years ago

If you want a standards based answer to 2, it would be to associate an LDP DirectContainer with an AnnotationList as the membership resource. Fedora4 already implements DirectContainers, and Triannon uses Containers to store Annotations ... but there would be some changes needed to get it to work in practice, and we've more than used up our Triannon development time for this calendar year.

I could build a prototype given a few days, but as you say, we haven't discussed CUD (R is easy) for anything in the IIIF space, and Annotations only in the W3C space, so I'm not sure of the value of such a prototype.

mikeapp commented 9 years ago

Our intent is to generate manifests whose otherContent points to lists managed in our annotation store.

Our annotation store allows creation/addition of an annotation to a specific list by specifying the list's URI in the within property. I'm sure that there are other approaches one could take, but this is simple and reasonably consistent with the data returned when the annotation is requested.

aeschylus commented 9 years ago

That will work with what we've created. Can individual annotations have a within property?

sdellis commented 9 years ago

It looks as though the ten-thousand-rooms examples provide a within property.

But much of the discussion this assumes that lists or layers exist at all, which is not required by the specs as far as I can tell. The only thing an annotation needs to have a relationship to a manifest is a URI value (currently a canvas id) assigned to the annotations "on" property. The only thing the client needs to make that relationship meaningful to the user is 1) an endpoint and 2) a way to query by annotations' "on" property.

The work we did this week was based on the above use case, which is what we have to work with, and which will continue to exist even when more robust server-side software is available.

-Shaun

On Fri, Aug 7, 2015 at 2:07 AM, aeschylus notifications@github.com wrote:

That will work with what we've created. Can individual annotations have a within property?

— Reply to this email directly or view it on GitHub https://github.com/IIIF/mirador/issues/589#issuecomment-128607995.

mikeapp commented 9 years ago

Individual annotations can have a within property. The Search API will provide a means of locating all annotations for a Canvas. From an individual Annotation is will be possible to follow the graph up to the Layer(s), if they exist. The Layers allow for conveniences in the UI, but I agree that they (and presumably even AnnotationLists, once Search is available) are not a requirement.

damooo commented 5 years ago

Hello, Is there any way now to do this? presently we are serving iiif annotationLists with their within property set to a layer object. In manifest, for each canvas, in it's otherContent array, we have references to multiple annotationLists, each list having their own within property setted to different layer. like, machine_inferred layer, user_space_layer, etc. now is there any interface to enable/disable specific layers? on Layers tab in sidebar, only image manipulation layers are being listed as of now.