Re: Language Maps and default language

The CG (probably just me, but with some approval) will likely release updated specs to address long-standing feature requests and clarify some inconsistencies. If you have some suggested wording and/or could create an issue for this, that would be great. Other things I'm aware of seem to be covered. 

Gregg Kellogg
Sent from my iPhone

> On Sep 20, 2016, at 5:15 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Ahh, yup.  The specification text isn't clear (IMHO) but the algorithm definitely is.  We'll fall back to some pre-processing to add a language of "" or "UND" before compaction.
> 
> Thanks Gregg, as always!
> 
> Rob
> 
> On Mon, Sep 19, 2016 at 2:07 PM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>>> On Sep 19, 2016, at 11:38 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
>>> 
>>> 
>>> Dear all,
>>> 
>>> I'd love some clarification around the expected behavior of language maps with a default language.
>>> 
>>> For example, in a context, one might use:
>>>   "label" : {"@id": "rdfs:label", "@container": "@language", "@language": "en"}
>>> 
>>> I would expect this to then add a language of "en" to any string that does not have a language set.  And indeed this works in the playground:
>>>     http://tinyurl.com/zn9jxkz
>>> 
>>> However, when loading the data from NQuads, this does not work:
>>> 
>>> _:b0 <http://www.w3.org/2000/01/rdf-schema#label> "bar" .
>>> _:b0 <http://www.w3.org/2000/01/rdf-schema#label> "fish" .
>>> 
>>> results in
>>> 
>>> {'@context': {
>>>     'label': {'@container': '@language', '@id': 'rdfs:label', '@language': 'en'}, 
>>>     'rdfs': 'http://www.w3.org/2000/01/rdf-schema#'
>>>   }, 
>>>   '@id': '_:b0',
>>>   'rdfs:label': ['bar', 'fish']
>>> }
>>> 
>>> rather than using the label key and assigning the default language of "en".
>>> 
>>> I would expect, per the playground:
>>> 
>>> {
>>>   "@context": {
>>>     "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
>>>     "label": {"@id": "rdfs:label", "@container": "@language", "@language": "en"}
>>>   },
>>>   "label": {
>>>     "en": [ "fish", "bar" ]
>>>   }
>>> }
>>> 
>>> 
>>> Thanks in advance for any thoughts.
>> 
>> Hi Rob, I agree that this is unintuitive, and is arguably a bug in the spec. (In general, IMHO, the spec is overly prescriptive in the algorithms, but some means of ensuring interoperability between implementations is necessary, and normative text that covers each permutation would be unwieldy; perhaps we can try better in a future CG version of the specs).
>> 
>> In this case, the algorithm is correct; the NQuads defines “bar” and “fish” as having no language, whereas the context provides a default language. If you look at the Term Selection algorithm [1], you’ll see that if the literal values had a language, it would prefer to use a language map. Note that the @language definition in the term does affect transformation from NQuads to expanded JSON-LD, so the literals come across without language. If, instead, you had the following:
>> 
>> _:b0 <http://www.w3.org/2000/01/rdf-schema#label> “bar”@en .
>> _:b0 <http://www.w3.org/2000/01/rdf-schema#label> “fish”@en .
>> 
>> You would get the language map back.
>> 
>> The @language definition within the term would be useful when expanding JSON-LD where the string values were “foo” and “bar”; the context would say that these should be considered to have @language “en”, but that’s because the JSON-LD is in compact form.
>> 
>> Gregg
>> 
>> [1] http://www.w3.org/TR/json-ld-api/#term-selection
>> 
>>> Rob
>>> 
>>> -- 
>>> Rob Sanderson
>>> Semantic Architect
>>> The Getty Trust
>>> Los Angeles, CA 90049
>> 
> 
> 
> 
> -- 
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049