Get feedback from the JHU team on how ATLAS is serving WAs

[jacobwegner]

@jabrah wrote in Slack:

It's long long overdue, but i'm hoping to record some thoughts about the structure of our current web annotations soon

Here are some things I've been wondering for the web annotations being served by ATLAS:

• Is it helpful to have both text (https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/0/text/) and html (https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/0/html/) bodies?
• If so, should we just combine multiple bodies into a single annotation (e.g. https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/0/)
• Does it work to use the CITE URN for a the Venetus A folio to key the web annotations? If not, what would be better?
• Is there anything ATLAS can do to help with discovery (providing a list of all possible annotations / collections given via a manifest URI (https://rosetest.library.jhu.edu/rosademo/iiif3/homer/VA/manifest), etc

[jabrah]

The current iterations of the JHU georeference annotations and ATALS' sentence level translation alignment annotations are functional in the custom Mirador 3 (M3) plugin. Some very specialize knowledge of CTS URNs as well as some fun hacks were needed to get then to show as they do.

To address your questions

• Helpful to maintain both plain text and HTML annotation bodies? I think it is fine to keep only the HTML body. The plain text version would be good to have if we or someone else wanted the annotations for some other purpose, but if we are only using the annotations for rendering to a user, only having the HTML body works fine.
• Use the CITE URN for Venetus A folio to key web annotations? As long as the identifier used across the various web annotation services is consistent, I have no preference. The current scheme seems to be working OK to me.
• Anything ATLAS can do to help with discovery? Your suggestion of providing a list of possible annotations and/or annotation collections definitely sounds interesting. I think discovery in some capacity would help.

One of the issues with the M3 plugin is how the plugin knows that there are ATLAS services that can provide annotations for given IIIF canvases. Right now things are fudged a bit with some hard coded links in the viewer. I don't know if this is feasible, but I think my ideal would be to have a service that can accept a IIIF Canvas ID (such as https://rosetest.library.jhu.edu/rosademo/iiif3/homer/VA/VA034VN-0536/canvas) and respond with the annotation collections associated with that canvas, or even just the URLs to those services. Then on the JHU side, we could attach this service URL to the IIIF data to make viewers aware of the service.

Other feedback

Annotations that target annotations: named entities, georeference, etc

Based on using our georeference annotations in the M3 plugin, there is some feedback I have about these kinds of annotations. I think it would be helpful for a web annotation viewer to have annotations that target other annotations to explicitly call out the targeted annotation in its target property. Not sure how possible this is. The current plugin parses the CTS URN to guess at the intended target annotation, which may not always be correct.

For example, a georeference annotation that targets some translated text:

{
  "type": "SpecificResource",
  "source": {
    "type": "Annotation",
    "id": "https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:35r/translation-alignment/622/text/"
  },
  "selector": {
    "type": "TextQuoteSelector",
    "exact": "Athens"
  }
}

@markpatton may be interested

[jacobwegner]

@jabrah I opened a new issue to discuss annotations targeting other annotations, (#90 cc: @markpatton ), just so I can keep discussion here to your feedback about "discovery"

[jacobwegner]

@jabrah So absent a full-fledged discovery service, how does this sound?

1) We add a new endpoint /wa/discovery/ 2) Pass the canvas id via a ?canvas_id param...e.g. /wa/discovery/?canvas_id=https://rosetest.library.jhu.edu/rosademo/iiif3/homer/VA/VA012RN-0013/canvas 3) We return a payload

What would you like that payload to look like?

{
    "collections": [
        "https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/audio-annotations/collection/compound/",
        "https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/named-entities/collection/compound/",
        "https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/collection/html/",
        "https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/collection/text/"
    ]
}

or something else?

[markpatton]

@jacobwegner @jabrah

One thought looking at this the need to normalize on IIIF 2 vs IIIF 3. On our side we normalized on IIIF 2 because of delays with IIIF 3, but probably forgot to communicate that fact. Sorry about that! So our web annotation service is pointing to uris using /iiif/ instead of /iiif3/. And now the mirador viewer is using IIIF 2. If you have already used the IIIF 3 URIs and its just a pain to change, no worries. We can hack around the issue.

The proposed structure seems completely fine to me, but let's hear from John who will be consuming it.

[jabrah]

The proposed discovery service looks good to me as well. I do agree with Mark about the /iiif/ vs /iiif3/ URIs

[jacobwegner]

Understood about IIIF3; I've changed the URIs within the ATLAS annotations to match.

Will try to have something done with the new TextQuoteSelectors and the discovery service by the end of the week.

[jacobwegner]

@jabrah:

I've got a preview instance that is set up with the discovery endpoint:

https://explorehomer-feature-wa-jm1koi.herokuapp.com/wa/discovery/?canvas_id=https://rosetest.library.jhu.edu/rosademo/iiif/homer/VA/VA035RN-0036/canvas

• translation alignments
• audio annotations

https://explorehomer-feature-wa-jm1koi.herokuapp.com/wa/discovery/?canvas_id=https://rosetest.library.jhu.edu/rosademo/iiif/homer/VA/VA012RN-0013/canvas

• translation alignments
• named entities
• audio annotations

You'll notice that I did tweak the URLs throughout; originally we were offering both a "text" and "html" version of the translation alignment WA, but since you've asked to standardize around just the "html" version, each of the urls for collections, annotation pages, and individual changes have dropped the "format":

e.g.

https://aniop-atlas-staging.eldarion.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/collection/html/

vs

https://explorehomer-feature-wa-jm1koi.herokuapp.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/collection/

Since this is a backwards incompatible change, I won't deploy to the aniop-atlas-staging instance until you've had a chance to update your application to make use of the discovery endpoint.

[jabrah]

@jacobwegner

I tried this out in our viewer, finally, and it seemed to work nicely. I have it integrated as a proof of concept with the discovery service URL baked into the UI, but when the service stabilizes, we can think about adding it to our IIIF manifests as a service block that the UI can access. No more magic URLs in the UI :)

[jacobwegner]

@jabrah Great! I'll work on getting the "stable" instance (aniop-atlas-staging.eldarion.com) deployed with this change, and eventually will spin down explorehomer-feature-wa-jm1koi.herokuapp.com

[jacobwegner]

@jabrah I've deployed the discovery endpoint to aniop-atlas-staging.eldarion.com:

https://aniop-atlas-staging.eldarion.com/wa/discovery/?canvas_id=https://rosetest.library.jhu.edu/rosademo/iiif/homer/VA/VA035RN-0036/canvas

When convenient (but no rush!), please update to aniop-atlas-staging.eldarion.com and let me know here, and I'll tear down the preview instance.

[jabrah]

I've updated the discovery endpoint, seems to work as expected.

[jacobwegner]

Thanks; I've shut down the preview instance.