ncsu-libraries / annona Goto Github PK

thanks for this work

I'd like to see one more feature come in to improve usability for users: add next and previous annotation buttons on the right top of the annotation text window. Of course, this feature could be enabled or (by default) disabled.

Jeau

Please add a LICENSE file to the project.

Thanks for this interesting IIIF project!

We are using Annona in the IIIF training and have come across an issue when a IIIF Image API URL ends in .jpg. It seems that currently Annona checks the file extension of the URL and if its jpg or png it treats it as a straight image rather than appending the info.json.

Here is an example manifest:

{
	"@context": "http://iiif.io/api/presentation/2/context.json",
	"@id": "http://962b3764-d27d-41ff-b833-045088bd6572-march",
	"@type": "sc:Manifest",
	"label": "Glen's fantastic March 2021 Manifest",
    "service": {
        "profile": "http://iiif.io/api/search/0/search",
        "@id": "http://sas.gdmrdigital.com/search-api/02a12caaedd1cfec04e9cb65ffd6f2f2/search",
        "@context": "http://iiif.io/api/search/0/context.json"
    },
    "metadata": [],
	"description": [
		{
			"@value": "[Click to edit description]",
			"@language": "en"
		}
	],
	"license": "https://creativecommons.org/licenses/by/3.0/",
	"attribution": "[Click to edit attribution]",
	"sequences": [
		{
			"@id": "http://124c1daa-5983-4040-a1c7-fbb71a034c62",
			"@type": "sc:Sequence",
              "viewingHint": "paged",
			"label": [
				{
					"@value": "Normal Sequence",
					"@language": "en"
				}
			],
			"canvases": [
				{
					"@id": "http://a292a51f-5975-497f-b9a4-8a962e380762-march",
					"@type": "sc:Canvas",
					"label": "Empty canvas",
					"height": 3024,
					"width": 4032,
					"images": [
						{
							"@context": "http://iiif.io/api/presentation/2/context.json",
							"@id": "http://3e071cbb-e37e-49c9-8b60-4d996885f5e8",
							"@type": "oa:Annotation",
							"motivation": "sc:painting",
							"resource": {
								"@id": "https://iiif.archivelab.org/iiif/img-8664_202009/full/full/0/default.jpg",
								"@type": "dctypes:Image",
								"format": "image/jpeg",
								"service": {
									"@context": "http://iiif.io/api/image/2/context.json",
									"@id": "https://iiif.archivelab.org/iiif/img-8664_202009$IMG_8664.jpg",
									"profile": [
										"http://iiif.io/api/image/2/level2.json"
									]
								},
								"height": 3024,
								"width": 4032
							},
							"on": "http://a292a51f-5975-497f-b9a4-8a962e380762-feb"
						}
					],
                    "otherContent": [
                        {
                            "@id": "http://localhost:8887/annotations1.json",
                            "@type": "sc:AnnotationList",
                            "label": "My fantastic annotations"
                        }
                    ],
                    "related": ""
				}
			]
		}
	],
	"structures": []
}

I have provided an annotationlist to the tag

<iiif-annotation annotationurl='" + annotationList + "' styling='table_view:true'></iiif-annotation>

with multiple resources on multiple manifests - I have started to understand that this is not the intended way to use the annotation board, but it might be an easy mistake.

In doing so, it can happen that the full image URL is not derived properly (likely based on the wrong manifest). If that happens, the image is loaded indefinitely in quick succession. I think it happens due to the fallback trying to resolve image URLs for iiif v3.

This way it might put a lot of unwanted load on an iiif server by the client and the effect is only visible in the browser console, not in the browser itself.

Hello all,

Firstly, many thanks for making this superb feature available- we've used it extensively in our latest online exhibition:
https://www.digitalexhibitions.manchester.ac.uk/s/qing/

While running accessibility checks on our site, they return a 'Buttons do not have an accessible name' flag. Is this something that can be addressed?

Best wishes,
John

What would be the best way to support Annona translating in other languages than english ?
The tag builder user interface in particular

Hello all,

Further to issue #53, I've noted two additional buttons on the Annona viewer that Google Lighthouse flags as needing accessible names:

1. button#nextPageButton.pageButton.toolbarButton.ltr
2. button#previousPageButton.pageButton.toolbarButton.ltr

Are you able to update these, as you did the last time?

Many thanks for all your assistance.

Best wishes,
John

Hi @dnoneill

Do you support v3 annotationPages as a parameter to Annona? I've been doing some testing on the following page adding the equivalent of within in IIIF 2 to some v3 annotations:

https://glenrobson.github.io/iiif_stuff/zooniverse/partof/

I think the annotation structure is correct and equivalent to the v2 within structure. It works in Mirador but it maybe because I suggested it here.

Do you do it differently or is it not something you've come across?

Thanks

During the Online IIIF Workshop last week we use the following Gitbook:

https://training.iiif.io/iiif-online-workshop/index.html

Participants were encouraged to have a IIIF image by day 2, a manifest by day 3 and a manifest with annotations by day 4. It would be great if we could add Annona as an example to day 4 to say now you've annotated your manifest using the SimpleAnnotationServer and Mirador here is a way to display those annotations in another tool.

For the workshop most participants don't have HTML skills and don't have access to web hosting so they use the Chrome Web Server to host their manifests and annotation lists. We used the Internet Archive for hosting IIIF images.

With this in mind it would be great if we could pass the AnntationList as a URL query parameter to a hosted version of Annona so participants can see their annotations in a different viewer. An example URL might be:

https://ncsu-libraries.github.io/annona/storyboard/#?iiif-content=http://localhost:8887/annotations.json

Although I've just realised this might cause problems as the localhost is http.... but I could host a http version of Annona for the workshop. Other examples of this type of deep linking we use in the workshop include:

Image API:

• UCD Image tool: https://jbhoward-dublin.github.io/IIIF-imageManipulation/index.html?imageID=https://iiif.archivelab.org/iiif/img-8664
• Open sea dragon: https://iiif.gdmrdigital.com/openseadragon/index.html?image=https://iiif.archivelab.org/iiif/img-8664/info.json

Presentation API:

• Various IIIF Viewers https://iiif.io/explainers/using_iiif_resources/#quick-links

The reason for using the iiif-content name is to link it to the Content state api, and I think this would be allowable as it states a IIIF resource rather than a Manifest:

https://iiif.io/api/content-state/0.2/#224-target-url

I tested Annona with one of the SAS exported annotation lists and it worked great!

We tried to configure a <iiif-storyboard> component with a dataURI like data:application/json;base64,W3sidHlwZSI6IkFubm90YXRpb24iLCJib2R5IjpbeyJ0eXBlIjoiVGV4dHVhbEJvZHkiLCJ2YWx1ZSI6ImphcmRpbiIsInB1cnBvc2UiOiJjb21tZW50aW5nIn1dLCJ0YXJnZXQiOnsic291cmNlIjoiaHR0cHM6Ly9paWlmLmVtZi5mci9paWlmLzMvcGV1dGluZ2VyLmpwMiIsInNlbGVjdG9yIjp7InR5cGUiOiJTdmdTZWxlY3RvciIsInZhbHVlIjoiPHN2Zz48ZWxsaXBzZSBjeD1cIjEzMzY5LjMwOTU3MDMxMjVcIiBjeT1cIjg1Ni42NzkyOTA3NzE0ODQ0XCIgcng9XCIyNTMuODgzNzg5MDYyNVwiIHJ5PVwiMTU5LjI4MTA5NzQxMjEwOTM4XCI+PC9lbGxpcHNlPjwvc3ZnPiJ9fSwiQGNvbnRleHQiOiJodHRwOi8vd3d3LnczLm9yZy9ucy9hbm5vLmpzb25sZCIsImlkIjoiI2E1MzliZGE3LTcwNzQtNDIzZS04MDMyLTZjMWEyNjY0N2EwMCJ9XQ== in the annotationurl attribute.

But it does not work :-(

Is there a way to pass annotations as "raw json" to the <iiif-storyboard> component ? (because our annotations are not served over http).
If not, what do you think about managing dataURI for annotationurl attribute ? (we can try to contribute this feature with a PR if you are ok)