41 Matching Annotations
  1. Sep 2025
  2. Feb 2023
    1. embedded: When a resource (A) is embedded within an embedding resource (B), the complete JSON representation of resource A is present within the JSON representation of resource B, and dereferencing the URI of resource A will not result in additional information. Example: Canvas A is embedded in Manifest B. referenced: When a resource (A) is referenced from a referencing resource (B), an incomplete JSON representation of resource A is present within the JSON representation of resource B, and dereferencing the URI of resource A will result in additional information. Example: Manifest A is referenced from Collection B.

      3.1 says all this already, so maybe these terms do not have to be called out unless this mirrors a template that the Editors prefer.

    2. Example of a Georeference Annotation

      I would like to see some of these sections shortened once the recipes exist or are proposed. This description could be much tighter with bullet point links to samples.

    3. extraterrestrial

      Maybe "non-terrestrial"? The idea is that other planets and fantasy places are not referenceable, but I think also not extreme altitudes like deep ocean or high atmosphere.

  3. Dec 2022
    1. https://example.iiif.io/0057-publishing-v2-and-v3/manifest.json

      I love this and it introduces a serious conversation that may not have happened yet... I believe the id should be a URI you can find a resource at and a reference to the thing it represents (that is, not just the digital Manifest, but the resource represented. In using the profile header, we are suggesting that this is a good way to refer to this Resource for IIIF 2 or IIIF 3 or HTML or XML or any other way this resource might be serialized. I really like this, but it is not common practice.

      More problematic is that if this were the convention outside of IIIF, then the suggestion of "manifest.json" at the trailing end of the URI becomes hostile. Much how DAMS might have some record number and then prefix or suffix the path with "/view" or "/iiif" or "/json" or "oai-pmh" it might be worth suggesting that the profile for these various things could always be used with the root URI we usually attach "info.json" to but also provide a standard way to request "/iiif/3.json".

      Separately, I wouldn't be against offering "iiif/3.xml" or ".rdf" versions as an extension.

    2. may either choose to return its default response (a v2 manifest), or it may choose to return a 406 Not Acceptable status code

      It might be more clear here to say that checking the profile is an intentional step the server must take, so one may just always get the default response. The request is not a guarantee, but the requester can/should check the profile/@context of the returned resource if it is important.

    3. the user

      This is much less likely to be a "user" and much more likely to be an application or developer, which makes a difference here. I cannot paste an @id into an address bar and predict the response, but I would expect that Mirador would know if it was anticipating Presi 2,3,n and make the correct call.

  4. Aug 2022
  5. Feb 2022
    1. { "id": "https://example.org/object1/canvas7#xywh=1000,2000,1000,2000", "type": "Canvas", "partOf": [{ "id": "https://example.org/object1/manifest", "type": "Manifest" }] }

      Could we maybe use line highlighting to call out the bit that is likely to be encoded as the actual content state?

    2. without focusing on any particular part

      The simplest form doesn't remove focus, but defers the opinion to the viewer or the Manifest. For example, Mirador preferences showing the first page in the standard range, where something else may show a grid of thumbnails.

  6. Oct 2021
    1. "annotations": [ { "id": "https://preview.iiif.io/cookbook/0269-embedded-or-referenced-annotations/recipe/0269-embedded-or-referenced-annotations/annotationpage.json", "type": "AnnotationPage" } ]

      highlighting

  7. Sep 2021
    1. "annotations": [ { "id": "https://preview.iiif.io/cookbook/0266-full-canvas-annotation/recipe/0266-full-canvas-annotation/canvas-1/annopage-2", "type": "AnnotationPage", "items": [ { "id": "https://preview.iiif.io/cookbook/0266-full-canvas-annotation/recipe/0266-full-canvas-annotation/canvas-1/annopage-2/anno-1", "type": "Annotation", "motivation": "commenting", "body": { "type": "TextualBody", "language": "de", "format": "text/plain", "value": "Göttinger Marktplatz mit Gänseliesel Brunnen" }, "target": "https://preview.iiif.io/cookbook/0266-full-canvas-annotation/recipe/0266-full-canvas-annotation/canvas-1" } ] } ]

      highlight lines

    2. "summary": { "en": [ "<p>Picture taken by the <a href=\"https://github.com/glenrobson\">IIIF Technical Coordinator</a></p>" ] }, "rights": "http://creativecommons.org/licenses/by-sa/3.0/", "requiredStatement": { "label": { "en": [ "Attribution" ] }, "value": { "en": [ "<span>Glen Robson, IIIF Technical Coordinator. <a href=\"https://creativecommons.org/licenses/by-sa/3.0\">CC BY-SA 3.0</a> <a href=\"https://creativecommons.org/licenses/by-sa/3.0\" title\"CC BY-SA 3.0\"><img src=\"https://licensebuttons.net/l/by-sa/3.0/88x31.png\"/></a></span>" ] } },

      removable for a minimum recipe

  8. Jul 2021
  9. Jun 2021
  10. Apr 2021
    1. name and as much as a name

      I understand why "name" is here instead of label but it is explained right below. The consistency is better with label here.