Support for Commenting and Tagging Annotations (W3C WebAnnotations)

[HenryH09]

Hello Kevin,

I couldn't find a way to natively build such (other)annotation as those described in the following cookbooks :

• https://iiif.io/api/cookbook/recipe/0266-full-canvas-annotation/
• https://iiif.io/api/cookbook/recipe/0021-tagging/

How do you envision such cases with the Jiiify Library ?

• Adding 2 more classes in the library for thoses annotation motivation (like PaintingAnnotation)? (but then more might come along)
• Or adding a generic web annotation class on top of Annotation that will support all the motivations listed here : https://www.w3.org/TR/annotation-model/#motivation-and-purpose
• Or would you prefer the library user to implement its own classes ? (the ContentAnnotation interface is only package accessible -- might not be an issue, I am not sure)

Thank you,
Henry

[ksclarke]

Good question. Jiiify wasn't really intended to be a full annotation library (its goal was really to hide that aspect behind specific classes). My hope was there would be a core set that could be handled like PaintingAnnotation. The weakness there is, as you note, what if that set grows and grows... in which case a generic web annotation class would be a better option. I have also been thinking of the third option in cases where a particular place wants to use a specific annotation that is not widely used in general in the IIIF community (though how one measures that I'm not sure).

You've laid the options out well. The above were my initial thoughts, but I'm open to input. Which would you, as a user of Jiiify Presentation, prefer?

Just looking at the "full list" of annotations (https://www.w3.org/TR/annotation-model/#model-12): tagging definitely looks like one I'd want to support. Linking? Commenting? Maybe I'd handle core ones as classes and then have a fallback that's a more general/generic web annotation class for other uses. I don't know if this list is considered static or likely to grow(?) I'm curious which of these you'd see wanting to use? We're not using any of the others at this point (though I'll talk to our metadata folks to see which we might envision using in the future).

[ksclarke]

So feedback from our IIIF metadata person:

• for general digital collection usage: bookmarking, tagging, classifying, linking
• for Sinai (one of our big projects): all those plus commenting, describing, identifying

I'll have to think about this. That's more than I was expecting. I'm curious if your list would overlap or add to this. Thanks for raising the issue, @HenryH09!

[ksclarke]

I do think I prefer classes, but I'm wondering what my threshold is for "there are too many and should be handled generically." And, whether it makes sense to handle some as classes (giving them priority) and shuffling everything else off into a generic one (which might be confusing? e.g., "Why are these given preference?") I could start with tagging and commenting and add as requested. If that's a fixed list, then there is a maximum number, and let use drive implementation. Still not decided... I'm just thinking out loud...

[HenryH09]

Thank you for the feedback.
I think we would be interested in tagging, commenting, describing, identifying and most likely linking for our usages.

As a user I think all options are valid. Of course the first one would be more convenient :) Also would help to have consistency while producing IIIF content. The second option might end up confusing because of some W3C Annotation specificities (? maybe not, I am not very familiar with those). The third option should always be available but might also bring some needed modifications to render these as they should/could be within the manifest.

I did the third option for now by creating a minimal commentingAnnotation class extending the Annotation class :

public class CommentingAnnotation  extends Annotation<CommentingAnnotation> {
   private static final String MOTIVATION = "commenting";
   
    public <C extends CanvasResource<C>> CommentingAnnotation(
   		 final URI id, 
   		 final CanvasResource<C> canvas,
          final MediaFragmentSelector canvasRegion) {
      super(id, canvas, canvasRegion);
      myMotivation = MOTIVATION;
  }
   
   public <C extends CanvasResource<C>> CommentingAnnotation(final String id, final CanvasResource<C> canvas,
          final MediaFragmentSelector canvasRegion) {
      this(URI.create(id), canvas, canvasRegion);
  }
   
   @Override
  public CommentingAnnotation setBodies(final AnnotationBody<?>... body) {
      return (CommentingAnnotation) super.setBodies(body);
  }
   
   @Override
  public CommentingAnnotation setBodies(final List<AnnotationBody<?>> bodyList) {
      return setBodies(bodyList.toArray(new AnnotationBody[0]));
  }
}

This allows me to easily create the content I was looking for.
However, on a side note, I am not (yet) able to produce the annotation the way it is done in the cookbooks, expecting:
"target": "https://iiif.io/api/cookbook/recipe/0021-tagging/canvas/p1#xywh=265,661,1260,1239"

from https://iiif.io/api/cookbook/recipe/0021-tagging/

but having :

"target": {
    "type": "SpecificResource",
    "source": "https://iiif.io/api/cookbook/recipe/0021-tagging/canvas/p1",
    "selector": {
        "type": "FragmentSelector",
        "conformsTo": "http://www.w3.org/TR/media-frags/",
        "value": "xywh=265,661,1260,1239"
    }
}

This is fine according to the documentation and properly supported by Mirador3 :

Parts of Canvases may be described using a Specific Resource with a Selector, following the patterns defined in the Web Annotation data model. The use of the FragmentSelector class is recommended by that specification, as it allows for refinement by other Selectors and for consistency with use cases that cannot be represented using a URI fragment directly. Parts of Canvases can be referenced from Ranges, as the body or target of Annotations, or in the start property.

Parts of Canvases may also be identified by appending a fragment to the Canvas’s URI, and these parts are still considered to be Canvases: their type value is the string Canvas. Rectangular spatial parts of Canvases may also be described by appending an xywh= fragment to the end of the Canvas’s URI.

However, to stick closer to the IIIF cookbook, would it be possible to choose between the 2 formats while targeting a canvas ?

[ksclarke]

Okay, thanks. I think I like the first as well. I'll do that. And, yes, my goal is to be able to roundtrip anything that's expressed in the cookbooks (though I'm a bit behind on this), so I'll provide a way to indicate which serialization format should be used. Thanks!

[ksclarke]

A first iteration of this is in the main branch now. It's not in a published version yet, though, because it's a breaking change and there are a few more I'd like to make along with it.