Simplify language assignment?

[azaroth42]

Although it's not clear from the specification, it turns out that language containers are handled correctly when they're just strings with no language associated:

{
  "@context":
  {"occupation": {"@id": "ex:occupation", "@container": "@language"}},
  "occupation": "Nindža"
}

Works at the same time as:

{
  "@context":
  {"occupation": {"@id": "ex:occupation", "@container": "@language"}},
  "occupation": {"en": "ninja"}
}

However multiple are not. This fails:

{
  "@context":
  {"occupation": {"@id": "ex:occupation", "@container": "@language"}},
  "occupation": [{"en": "ninja"}, "ninjas"]
}

And has to be, instead:

{
  "@context":
  {"occupation": {"@id": "ex:occupation", "@container": "@language"}},
  "occupation": {"en": "ninja", "": "ninjas"}
}

This seems like an improvement over the lists of @language/@value pairs?

[azaroth42]

Hrm. I think this is a bug in the JSON-LD algorithm. The spec is clearer in the language map definition that it must be a node object, not a string.
Thread on W3C forum: https://lists.w3.org/Archives/Public/public-linked-json/2016Mar/0003.html

[azaroth42]

And reply from @gkellogg:

Hi Rob, you’re correct that to be a language map, the term must be defined using @container: @language, and, the value must be an object with keys as described. However, the JSON-LD expansion algorithm allows the same key to be used in ways that it is not interpreted as a language map, notably those you mention

So we could do this in 3.0 (defered until then anyway)

[azaroth42]

Hmm... note digitalbazaar/jsonld.js#151 (comment)

"" cannot be used as a key in certain languages (e.g. PHP)

There is an "undefined" language key though: UND

[azaroth42]

NB ... the PHP issue was resolved in 7.1, opening the door for the preferable, round-trippable {"": "un-languaged text"} pattern.

Propose that for 3.0 we should go ahead with this revised pattern for i18n.

[azaroth42]

Dear IIIFers ... please can you 👍 this proposal:
json-ld/json-ld.org#480 (comment)

[azaroth42]

Discussion 08/30: Everyone likes the pattern, and assuming that everything goes well with standardization and implementations of it, we'll adopt it.

[azaroth42]

Discussion at Getty AV:

• Consistency is better than inconsistency (or many many options). Every exception is an additional barrier to entry.
• But raises the very initial barrier (e.g. need to understand language map to understand label)
• Somewhat more complex for content creators, as there is additional constraints on how simple labels must be provided.
• Nicer for client developers, which might encourage more clients.
• OTOH, there are currently many more developers of content publishing rather than clients.
• Good for International Image Interoperability. We're saying that internationalization is a good thing, which is valuable.

[zimeon]

👍 agreed at Toronto WG meeting.

Consensus was that the regularity and promotion of internationalization outweigh concerns over slight increase in complexity for simple case. It was noted that the 3.0 spec should change the example to make clear why one would have two values for one language (current example lists "and a second description" for the second value). It should also be noted that use of @none and hyphenated language values (e.g. ar-latn) means that client implementations should be aware of these as possible key values in the map.

[azaroth42]

Closed by #1298.