JSON-LD term mapping collisions: label, value

[azaroth42]

Assuming #755, then we have a collision between the definitions of value and label in the IIIF and Web Annotation contexts. IIIF would have value as a language map, as the only time we use it is as the value of a metadata pair. Web Annotation (WA) on the other hand uses it in several places, including for non-linguistic content such as the value of a CssStylesheet or a FragmentSelector.

Assuming #1186, our context would trump the WA context due to the ordering, making all of those fields invalid as they are not language maps. In JSON-LD 1.1 this can be worked around, by asserting that our value mapping only applies within the context of metadata. See: https://json-ld.org/spec/latest/json-ld/#scoped-contexts This would allow the other uses to fall through to the WA context.

Unfortunately we allow label anywhere, including on AnnotationCollections. The WA model also recommends label on AnnotationCollections:

A human readable label intended as the name of the Collection. Collections SHOULD have 1 or more labels, and the value MUST be a string.

So we have a nasty decision to make :(

[azaroth42]

Further research ... maybe not. Clarifying here:
json-ld/json-ld.org#521

[azaroth42]

Adding discuss as the solution to the collision is a JSON-LD 1.1 feature, which thus impacts the discussion on #1192 and similar.

[azaroth42]

Summary:
The only affected property is label on AnnotationCollection which is important to IIIF use cases to be internationalized. value can remain a string in the Annotation scope and a language map (pending #755) in the IIIF scope using type based scoped contexts in JSON-LD 1.1 (pending #1192).

Options:

• Accept that label on AnnotationCollection cannot be internationalized per Web Annotation and adopt the WA context.
• Overwrite the WA context with our own, making IIIF AnnotationCollections representation-wise incompatible with WA AnnotationCollections. Raise the issue of internationalization with the W3C.
• Rename label to a different key in IIIF to avoid the conflict. This would be all uses of label, and thus problematic
• Associate a second key for language mapped strings along with label, requiring developers to always check both ... reducing happiness and in conflict with other accepted patterns.
• Use our own class for AnnotationCollections.

[azaroth42]

AS2 uses the different key option: https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues

[cubap]

I'm shooting from the hip, so this may not be helpful (that is, I have not educated myself on the history of this, but it has been kicking around my mind since I spoke up in the meeting).

I think what is missing here is some sort of "default" so that anything can since something to show. In most cases, I think there is a preference for some language by the content holder, even if others are available. label is not quite the same as, say, description where the different translations are more useful to the consumer in equal weight. For example, even English speakers are likely to recognize the Latin title of many works as primary to the translation. If we put it in the map, it is likely to be redundant with an option and one or the other would be left out by lazy applications:

"label" : {
    "default" : "Here's your title",
    "en" : "Here's your title",
    "en-GB" : "Here's youour title",
    "en-US" : "Here's yer title"
}

If it isn't too custom, maybe we can lean towards a default with an array, so ["string"] and "string" are both expectable in JSON-LD. The [1] position could be a map for alternatives.

"label" : [ "Here's your title", {
    "en" : "Here's your title",
    "en-GB" : "Here's youour title",
    "en-US" : "Here's yer title"
}

If I didn't translate my title or cannot assert the language (either because it is outside of standard encoding or unknown to the encoder), I may only place a "string". As a developer, I would have no problem looking in the next position for localization, but offering label[0] || label as the initial display.

~ 2 cents.

[azaroth42]

Per discussion on #1400, we should choose which context is our primary one and adopt it. In this case, our primary context is Presentation 3, and thus its definition of label wins out. This is very very unlikely to cause problems, as label on Collections is not a core feature of the Web Annotation model.

Propose that we document the inconsistency and move on.

[azaroth42]

Closed in effect by #1408