Linking an annotation targeting a canvas to the Manifest

[glenrobson]

Linking an annotation targeting a canvas to the Manifest

Use case

Usually annotations point to a Canvas or Canvas fragment. This can cause problems for annotation consuming viewers as the Canvas identifier doesn't have to resolve. To get the information from a Canvas a viewer needs access to the containing Manifest. This recipe would look at the annotation structure that can allow this.

Implementation Note

A link to a manifest can be achieved by using a partOf property on the Canvas. The Annotation target can be expanded from the short URI fragment into a SpecificResource that points to a Canvas object. This Canvas object can then contain the partOf property pointing to the Manifest. A example of this Annotation is shown below:

{
    "id": "https://example.com/anno/1",
    "type": "Annotation",
    "motivation": "tagging",
    "body": {
        "type": "TextualBody",
        "format": "text/plain",
        "language": "en",
        "value": "Text of the annotation"
    },
    "target": {
        "type": "SpecificResource",
        "source": {
            "id": "https://example.com/canvas/1",
            "type": "Canvas",
            "partOf": [{
                    "id": "https://example.com/manifest.json",
                    "type": "Manifest"
            }]
        },
        "selector": {
            "type": "FragmentSelector",
            "conformsTo": "http://www.w3.org/TR/media-frags/",
            "value": "xywh=570,1472,1814,314"
        }
    }
}

[glenrobson]

Cookbook authors agree this is a recipe.

[benwbrum]

This is very well timed, since--in addition to the specific use case described, it can serve as an annotation discovery mechanism for e.g. searching Github for annotations targeting a particular manifest.

[benwbrum]

I've modified a development version of AudiAnnotate to create annotations of this format, to test out a partOf-based annotation discovery service for annotations stored on Github. Here's the (Github UI-based) result: https://github.com/search?q=partOf+https%3A%2F%2Fpublic.aviaryplatform.com%2Fiiif%2Ftb0xp6v94p%2Fmanifest&type=Code

[giacomomarchioro]

A preview is available here:

https://preview.iiif.io/cookbook/0306-linking-annotations-to-manifests/recipe/0306-linking-annotations-to-manifests/

There are still some issues:

• the link to the two examples all points to the Manifest, the first should point to the AnnotationPage
• Annona does not support IIIF presentation API 3.0

[dnoneill]

@giacomomarchioro This is actually because the tag builder was rebuilt, Annona is 3.0 compatible. I am fixing the linking for Annona. Edit: It is now fixed. The Annona linking is fixed.

[giacomomarchioro]

@dnoneill thanks a lot now it works perfectly!

[giacomomarchioro]

We still have some issues with the Jekyll system, basically, the JSON link of the AnnotationPage in https://iiif.io/api/cookbook/recipe/0269-embedded-or-referenced-annotations/ and of https://preview.iiif.io/cookbook/0306-linking-annotations-to-manifests/recipe/0306-linking-annotations-to-manifests/ points to the manifest, this because manifest is set to "manifest.json" in the include statement:

{% include manifest_links.html viewers="Annona" manifest="manifest.json" annotationurl="annotationpage.json" %}

In the case of 0269 the AnnotationPage cannot be viewed without providing the original manifest that's the point of 0306 where the manifest link is provided inside the annotation Page. Annona seems to use a query parameter to perform this task, we were wondering how to explain this mechanism to not create confusion regarding supplementary pieces of information not in the original Annotation Page. We wanted to ask to @dnoneill for some ideas and guidance.

[dnoneill]

If I understand the question correctly, you don't want users to get confused because the view of the annotation includes the manifest url? I would just update this page to not include the manifest url. I originally included it as a just in case because when I first started some annotations didn't point to the image or would only point to the canvas and not link the manifest. But I would imagine that isn't a problem with these examples, so I would remove &manifesturl={{manifest_url |strip}} from the highlighted line: https://github.com/IIIF/cookbook-recipes/blob/master/_includes/viewer_link.html#L31.

[giacomomarchioro]

@dnoneill sorry for the late reply, probably should be better to discuss it further, I think that is nice to show that Annona can produce and handle the AnnotationPage and the manifest with the query parameters, but we must find a way to show the correct JSON when clicking the link.

[dnoneill]

@giacomomarchioro I am assuming you are talking about the url for the JSON link? I wonder if you update the include to be: annotationpage.json
You should be able to update manifest_links.html to this and it should fix it:

[JSON-LD]({% if include.annotationurl %}{{include.annotationurl}}{% else %}{{ include.manifest }}{% endif %}) {% for viewerTxt in viewers %}{% assign viewer = viewerTxt | strip %}| {% include viewer_link.html type=viewer manifest=include.manifest annotationurl=include.annotationurl %}{% endfor %}

[giacomomarchioro]

thanks a lot @dnoneill it works well, we disccussed it in the last meeting however we think that it makes more sense that a signle annotation page without link to the manifest can't be viewed directly see #397 because the information inside the AnnotationPage is not enoough. I hope that it is okay for you.

While when we add the manifest's link inside the annotationpage like in thise recipe the viewer could retrive the Manifest link. Regarding this point if a remember well once Annona had the support of this feature (automatically get the manifest Url from the annotation page...) , but at the moment it seems is not working, am I wrong?

Thanks again for all your support and patiance.

[dnoneill]

Yeah I think it got removed at request. We can add it back in.