Make label definition consistent and internationalized, rather than follow W3C annotations

[azaroth42]

Links

• Original Issue: label in metadata in annotation resources inherits annotation context definition api#1834
• Pull Request: revert to always use label as language map api#1851
• Preview: [to come]

Background and Summary

The design patterns for IIIF sometimes lead to conflicting requirements, and the role of the editors and TRC is to try to resolve those conflicts to the best practical solution. This issue is one of those cases. In particular, Internationalization is important, as is Reuse of Standards and Best Practices.

We have taken the reuse of standards very seriously, however the W3C Web Annotation data model defines the label for an AnnotationCollection to be a string, and not have any language features. This is documented in the current draft, and the label definition collision discussed explicitly. This conflicts with the first I in IIIF and the world-wide use design principle.

Further and more problematic, label is also used in requiredStatement and metadata, not just as a human readable string for the AnnotationCollection itself. The definition of label as a string would be active for everything that is "below" the AnnotationCollection, such as the content resources being annotated. Thus, the definition would be applied to the label field in those properties, resulting in IIIF defined structures being inconsistent and not-internationalizable.

If there was a metadata property on an Annotation, it would come out looking like:

{
  "type": "Annotation",
  "metadata": [ {"label": "string", "value": {"en": "value here"} } ]
}

Which is much worse than having a single class (AnnotationCollection) that can't have an internationalized label.

Proposed Solution

The proposal is that we should enforce the definition of label to be as per the IIIF context - a language map allowing ease of internationalization - on all resources in IIIF content. This can be accomplished technically by redefining label after importing the Web Annotation context, as contexts are processed sequentially to produce the active context.

The documentation can then use label consistently, and section 4.7 can be updated to explain the rationale for overriding the Annotation context.

Further Notes

In defense of the Annotation specification work, language maps in JSON-LD 1.0 are not as functional as they are in 1.1 and would have introduced even worse inconsistencies. Scoped contexts do not exist in 1.0 and there is thus no opportunity to scope the definition of label only to as used on an AnnotationCollection. A future WG for Annotations in the W3C could publish a 1.1 context that fixed these issues with very little effort, and use this decision as grounds for doing so.

[aisaac]

As discuss in the May 2019 Call, the issue would be clearer if the example showed a label on an Annotation or an AnnotationCollection. The current example may be correct but it's a bit indirect...

[cubap]

For the record, from the call: IIIF/api#1834 (comment)

And the discussion on this is reasserting the IIIF context over the Web Annotation context within AnnotationCollections and enforcing the expectation that it is a language map. Although WA also uses rdfs:label, the IIIF context adds details that are not included and the WA model states "the value must be a string" at https://www.w3.org/TR/annotation-model/#annotation-collection

[mejackreed]

From a practical viewer implementation standpoint, we may still want/have to account for the label as a string when consuming annotations from an external WebAnnotation server that may not have the IIIF context. 👍 for the push for consistency.

[azaroth42]

Issue 26 (Make label definition consistent and internationalized, rather than follow W3C annotations)

+1: 30 [ahankinson aisaac andrewgunther azaroth42 beaudet cubap dismorfo emulatingkat gigamorph glenrobson irv jbhoward-dublin jonhartzler joshuago78 jpstroop jtweed julsraemy markpatton mattmcgrattan mcwhitaker mejackreed mikeapp mixterj regisrob rentonsa rsinghal scossu sredick tpendragon zimeon]
0: 0 []
-1: 0 []

Result: 30 / 30 = 1.00

Super majority is in favor, issue is approved