Extension to Mirador Use Cases @Yale
A demo site is set up at http://mirador-demo.iiif.yale.edu.
The Mirador core has a layout called workspace which can host multiple windows but the window is wired to host a canvas and is not resizable nor reposition-able. We attempted initally to create a new type of window for annotations inside the existing workspace but for the moment it seemed too risky so we then took the approach of embedding the Mirador instance of our own layout manager and create other types of windows outside the Mirador core. We are using a third-party library (Golden Layout) to manage the windows.
Annotations are required to belong to a single layer in Yale extensions. The endpoint supports an additional method to facilitate the scheme:
getLayers() // returns an array of all available layers
The annotation editor also has a dropdown menu for layer selection.
An annotation can annotate another annotation. The front-end needs a way to distinguish between the "traditional" annotations annotating a canvas fragment and the "new" annotations annotating other annotations.
The current kludge for that is to set the annotation["on"]["@type"] field to "oa:Annotation" while the
"traditional" annotation sets it to oa:SpecificResource.
In many cases the word/sentence/paragraph/section which the user wants to annotate is scattered over multiple canvases.
We are implementing multiple annotation["on"] attributes for this problem.
To persist the change in order (in an annotation list) that happens from the client, the endpoint (and the client) has to support either saving a list (vs. individual annotations) or a method that specifically re-orders annotations in a list.
The latest Mirador provides sidebar menu for ranges (of canvases) defined in the manifest. Sometimes the user needs a similar concept for annotations inside a single canvas. For example, a large mural painting represents a story and the researcher wants to organize parts of the painting as chapters, scenes, etc.
One way to deal with it is to define a parent-child relationship between annotations. For the short term we have determined that approach is too complicated and instead tried to use tags to facilitate this. For example, we are using a JSON definition that looks like the following for a parser code to parse.
[
[
{ "label": "Chapter 1", "tag" : "chapter1" },
{ "label": "Chapter 2", "tag" : "chapter2" },
{ "label": "Chapter 3", "tag" : "chapter3" },
...
],
[
{ "label": "Scene 1", "tag" : "scene1" },
{ "label": "Scene 2", "tag" : "scene2" },
{ "label": "Scene 3", "tag" : "scene3" },
...
]
]
Then the user will create a "marker" annotation for each chapter and scene, e.g., create one, set the content as "Chapter 1, Scene 1" and add tags "chapter1 scene1", and all annotations (transitively) annotating that annotation will be parsed to belong to that scene.
- A hybrid of the rectangle and the polygon so it is a polygon but lines snap 90 degrees vertically and horizontally -- useful for annotating documents (vs. pictures).
- To be able to close free-form shapes so the user can do mouse-over to the inside of the shape.
- To be able to designate certain annotations to show/hide or be highlighted.
- To be able to focus on one or more shapes programmatically and dim the rest of the canvas.
- Curves (e.g. Bézier)
Yale Extension has a repository at https://github.com/yale-web-technologies/yale-mirador. It contains the Mirador core as a Git submodule and has additional JavaScript and styles on top of the core.
We have taken the approach of embedding Mirador core as an HTML div element (as opposed to iframe).
The fact that jQuery is embedded in the core causes issues when embedding it to other systems that includes jQuery, e.g., Ruby on Rails, Drupal, etc.
We had to override some styles defined in Mirador to make it work with the embedding system. See https://github.com/yale-web-technologies/yale-mirador/blob/master/src/css/mirador.less.
Some issues in accessing the core from the embedding environment may be inferred from the MiradorProxy code at https://github.com/yale-web-technologies/yale-mirador/blob/master/src/js/mirador-proxy.js as we try to limit the interfacing code in this file.
We had to modify the IIIF Mirador core code in our fork to make it work with our system. Hopefully these modified features will be implemented in the core in the near future.
- Image window (annotation overlay) checks annotations for its type and skips "annotations of annotations" for associating paper.js shapes with them.
- The image window subscribes to
ANNOTATION_FOCUSEDevent and pan/zoom to the selected annotation and highlight it. - Access
.sp-cancelelement only when it exists (breaks when annotationCreation is false.) -- this is probably a bug rather than a missing feature.