For discussion only: translation alignment web annotations #2

jacobwegner · 2019-12-04T18:39:59Z

The samples in this PR would be individual web annotations within a WA collection.

My organizing idea is that there would be a 1:1 relationship between folios and collections, keyed off either the folio urn (urn:cite2:hmt:msA.v1:12r), image urn (urn:cite2:hmt:vaimg.2017a:VA012RN_0013), image id (https://image.library.jhu.edu/iiif/homer%2FVA%2FVA012RN-0013) or canvas id (https://rosetest.library.jhu.edu/rosademo/iiif/homer/VA/VA012RN-0013/canvas)

e.g. accessing/wa/urn:cite2:hmt:vaimg.2017a:VA012RN_0013/ would return an annotation collection containing one or more annotations for each line within urn:cite2:hmt:msA.v1:12r.

jacobwegner · 2019-12-04T18:41:01Z

wa_examples/html_wa.json

+    "urn:cts:greekLit:tlg0012.tlg001.msA:1.1-1.7",
+    {
+      "type": "SpecificResource",
+      "source": {


I thought it best following from @markpatton's mockups to target the Canvas; happy to swap this out for something else if desired

I think that is good for the moment.

jacobwegner · 2019-12-04T18:41:23Z

wa_examples/html_wa.json

+      },
+      "selector": {
+        "type": "ImageApiSelector",
+        "region": "pct:6.11,22.52,46.75,15.01"


https://image.library.jhu.edu/iiif/homer%2FVA%2FVA012RN-0013/pct:6.11,22.52,46.75,15.01/full/0/default.jpg

I see this is using ImageApiSelector from https://iiif.io/api/annex/openannotation/
I'm not sure it can be used with a Canvas. I think its meant to be used directly with IIIF Image URI.

This starts to beg the question of whether to use IIIF 2 or 3. We've been playing it a little loose. The examples I gave in the last doc used IIIF 3 and the recommended FragmentSelector with Canvas. For the moment I think we should just continue with IIIF 3 with /iiif3. (I may try to join the IIIF 2 and 3 endpoints using content negotiation.)

jacobwegner · 2019-12-04T18:42:29Z

wa_examples/html_wa.json

+      }
+    }
+  ],
+  "body": [


I chose two body entries, with each entry identifying the language.

We could also have a single body with HTML representing both sides of the alignment (similar to https://gist.github.com/jacobwegner/eb3de155d9d7a62cdf4c48838cecb7ed#file-html_body-json)

I think this is a good start. Let's see how it looks slapped into Mirador 3.

jacobwegner · 2019-12-04T18:42:58Z

wa_examples/text_wa.json

@@ -0,0 +1,32 @@
+{


similar to html_wa.json, just returning newline delimited text

Makes sense.

jacobwegner · 2019-12-04T18:51:06Z

wa_examples/html_wa.json

+{
+  "id": "/wa/translation-alignment/QWxpZ25tZW50Q2h1bmtOb2RlOjE=",
+  "type": "Annotation",
+  "target": [


given that the annotation will be part of an annotation keyed off of the folio urn, I've just referenced the URN for the lines here, but if we felt like an additional target to the folio urn (or image urn or canvas id or image id, as discussed in the PR body), happy to add it.

I think this should be sufficient.

jacobwegner · 2019-12-04T20:23:43Z

@markpatton thanks for the feedback; will definitely update to use /iiif3.

On the issue of using target::selector-type of Canvas::FragmentSelector vs Image::ImageApiSelector, the bounding box information we have is currently in percentages, and that's why I ended up specifying region in that initial example:

{
  "type": "ImageApiSelector",
  "region": "pct:6.11,22.52,46.75,15.01"
}

If we use FragmentSelector, the spec says the percentage values need to be integers (according to https://www.w3.org/TR/media-frags/#naming-space)

{
  "type": "FragmentSelector",
  "value": "xywh=percent:6,23,47,15"
}

resulting in a slightly less precise bounding box
https://image.library.jhu.edu/iiif/homer%2FVA%2FVA012RN-0013/pct:6,23,47,15/full/0/default.jpg

vs:
https://image.library.jhu.edu/iiif/homer%2FVA%2FVA012RN-0013/pct:6.11,22.52,46.75,15.01/full/0/default.jpg

I could explore doing pixel-based values, but it'd be great if we could retain the precision of the values as encoded within the CEX.

Would targeting an Image and using ImageApiSelector allow us to achieve that? Or if we must target Canvas, is there another way you can think of to pass in that bounding information with the selector?

markpatton · 2019-12-04T20:41:32Z

@jacobwegner

Targeting the Canvas is useful because it connects to the image and the IIIF Manifest. It puts you right in the middle of the linked data graph. Targeting the image is meaningful, but you are not connected to the other objects without some more info.

I think a small loss of precision targeting the canvas with FragmentSelector is ok in this case. You'd have to know the width/height to use pixel values which you might have so just rounding the percentages should be ok. Let's see what it looks like. If it looks bad, we can revisit.

jacobwegner · 2019-12-04T20:51:09Z

@markpatton Thanks for clarifying. If we need to use FragmentSelector, I think I will end up converting to pixels, as the precision does look it will be an issue when a single line is in play:

Full precision:
https://image.library.jhu.edu/iiif/homer%2FVA%2FVA012RN-0013/pct:16.32,25.23,33.23,2.48/full/0/default.jpg

Integer precision:
https://image.library.jhu.edu/iiif/homer%2FVA%2FVA012RN-0013/pct:16,25,33,2/full/0/default.jpg

Pixels:
https://image.library.jhu.edu/iiif/homer%2FVA%2FVA012RN-0013/855,1760,1741,173/full/0/default.jpg

jacobwegner · 2019-12-04T21:16:48Z

wa_examples/text_wa_canvas_image.json

+  "id": "/wa/translation-alignment/QWxpZ25tZW50Q2h1bmtOb2RlOjE=",
+  "type": "Annotation",
+  "target": [
+    "urn:cts:greekLit:tlg0012.tlg001.msA:1.1-1.7",


@markpatton one other idea I had, what if we targeted the canvas and image (and use the appropriate selectors).

(otherwise I'll just target the URN and canvas and convert the FragmentSelector value to pixels)

jacobwegner · 2019-12-04T23:32:43Z

I've deployed an demo instance:

Collection for urn:cite2:hmt:msA.v1:12r in text format:

https://explorehomer-atlas-dev3.herokuapp.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/collection/text/

and HTML:

https://explorehomer-atlas-dev3.herokuapp.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/collection/html/

sample WA in in text format:

https://explorehomer-atlas-dev3.herokuapp.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/0/text/

There are now four targets in each WA:

A URN corresponding to the greek lines in the WA
Canvas::FragmentSelector (with percentages rounded to integers)
Image:: ImageApiSelector (full precision percentages)
an image request URI that I found helpful to debug the bounding box being conveyed in the selector

Happy to prune it back to the URN and Canvas; if we do that, I'll make a final pass to update that FragmentSelector to use the most precise value (in pixels).

markpatton · 2019-12-05T15:15:54Z

@jacobwegner

Looking good. I'll let Reuben leave some feedback as he tries to use it. My only thought so far, is that while relative URIs as property values are supported and look correct, I prefer absolute URIs for ease of processing.

jacobwegner · 2019-12-05T15:59:42Z

Sounds good–I've switched to absolute URIs and will happily address any feedback from @GroovinChip that will aid what needs to happen on his end.

GroovinChip · 2019-12-10T18:11:26Z

Okay I have taken a look through these links. Something I notice right off the bat that we need to address is standardizing URIs. Right now, our web annotations for Rose follow this format:
https://rosetest.library.jhu.edu/rosademo/iiif3/rose/SeldenSupra57/1r/canvas
where my plugin takes this iiif3 URI and swaps out the iiif3 for wa for whichever canvas the user happens to be looking at. I think a standardized URI will be helpful, and once we firmly decide which format we will take for the annotations I can start handling those cases. Right now I only look for the body property of the web annotations we made for Rose.

jacobwegner · 2019-12-10T18:45:46Z

I think this problem is what @markpatton outlined in his document "Initial thoughts on IIIF and CITE":

But Web Annotation does not solve the problem of finding associated resources. Suppose each source of Web Annotations (JHU, Eldarion, possibly other partners) can return an AnnotationCollection targeting a resource. Then what we need is searchable index that lets us find each AnnotationCollection targeting a specified resource. (This could also be extended to deal with the mapping between CITE urns and IIIF images. Does that make sense?)
If other search criteria are needed, they could also be added. These simple documents could be indexed easily by something like Elasticsearch.

Whether ElasticSearch (or a citation service that @jtauber had designed but not yet implemented a couple of years ago in support of the Scaife Viewer ecosystem), that service could help connect a particular canvas / manifest to annotations.

The web annotations linked to in my comment above are generated off the CITE urn; I could re-generate them based on the canvas IDs within https://rosetest.library.jhu.edu/rosademo/iiif/homer/VA/manifest if desired.

I wonder for now if there could be just a simple static file for the https://rosetest.library.jhu.edu/anniop/ Mirador instance that says given canvas id foo what are the available annotations?

GroovinChip · 2019-12-17T19:38:13Z

Done using https://explorehomer-atlas-dev3.herokuapp.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/0/text/

GroovinChip · 2019-12-19T18:32:33Z

Using the https://explorehomer-atlas-dev3.herokuapp.com/wa/urn:cite2:hmt:msA.v1:12r/translation-alignment/collection/html/

jacobwegner · 2020-04-23T09:51:57Z

The functionality from this PR was re-implemented in explorehomer-atlas/pull/30

add samples for further elab

2574089

jacobwegner commented Dec 4, 2019

View reviewed changes

add an Image target

e8f8ad5

jacobwegner commented Dec 4, 2019

View reviewed changes

jacobwegner added 2 commits December 4, 2019 17:09

backport wac and wa from delarose and adapt

682e2db

sort and add requests

f7a36ec

prefer absolute URLs

72ef6e3

This was referenced Dec 12, 2019

Share alignment payload for HMT data jhu-digital-manuscripts/AnIOp#32

Closed

Convert Homer translation alignment to W3C annotation format. jhu-digital-manuscripts/AnIOp#20

Closed

Ingest Homer Multitext into ATLAS jhu-digital-manuscripts/AnIOp#23

Closed

jacobwegner mentioned this pull request Feb 28, 2020

ATLAS: Sentence-level translation alignment data jhu-digital-manuscripts/AnIOp#46

Closed

jacobwegner added 5 commits March 16, 2020 10:02

override endpoint

a2f7ba6

update for new reference format

b8f252e

update endpoint

ed68396

update to textAlignmentChunks

a008bc2

prefer absolute URLs for next / prev

c65c428

jacobwegner closed this Apr 23, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

For discussion only: translation alignment web annotations #2

For discussion only: translation alignment web annotations #2

jacobwegner commented Dec 4, 2019 •

edited

Loading

jacobwegner Dec 4, 2019

markpatton Dec 4, 2019

jacobwegner Dec 4, 2019

markpatton Dec 4, 2019

jacobwegner Dec 4, 2019

markpatton Dec 4, 2019

jacobwegner Dec 4, 2019

markpatton Dec 4, 2019

jacobwegner Dec 4, 2019

markpatton Dec 4, 2019

jacobwegner commented Dec 4, 2019

markpatton commented Dec 4, 2019 •

edited

Loading

jacobwegner commented Dec 4, 2019

jacobwegner Dec 4, 2019

jacobwegner commented Dec 4, 2019 •

edited

Loading

markpatton commented Dec 5, 2019

jacobwegner commented Dec 5, 2019

GroovinChip commented Dec 10, 2019

jacobwegner commented Dec 10, 2019

GroovinChip commented Dec 17, 2019

GroovinChip commented Dec 19, 2019

jacobwegner commented Apr 23, 2020

For discussion only: translation alignment web annotations #2

For discussion only: translation alignment web annotations #2

Conversation

jacobwegner commented Dec 4, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jacobwegner commented Dec 4, 2019

markpatton commented Dec 4, 2019 • edited Loading

jacobwegner commented Dec 4, 2019

Choose a reason for hiding this comment

jacobwegner commented Dec 4, 2019 • edited Loading

markpatton commented Dec 5, 2019

jacobwegner commented Dec 5, 2019

GroovinChip commented Dec 10, 2019

jacobwegner commented Dec 10, 2019

GroovinChip commented Dec 17, 2019

GroovinChip commented Dec 19, 2019

jacobwegner commented Apr 23, 2020

jacobwegner commented Dec 4, 2019 •

edited

Loading

markpatton commented Dec 4, 2019 •

edited

Loading

jacobwegner commented Dec 4, 2019 •

edited

Loading