Re: Acceptable values for @container:@language fields?

> On Mar 10, 2016, at 5:03 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Dear all,
> 
> In the spec, it seems reasonably clear that if a key is defined in the context as being @container: @language, then the value in the JSON MUST be an object, with the keys of BCP47 language strings.  However the playground also accepts the following:
> 
> * Just a string (does the expected thing of subj pred "string")
> * Array of strings (does the expected thing of multiple predicates)
> * Object with empty string as key (does the expected thing)
> 
> It does not error on an array of strings and objects, but does not do the expected language thing according to the above points -- instead it treats the object as a blank node.  Which is probably better ... but not consistent with the spec.
> 
> So ... are these oversights in the algorithm and intended not to work, or are they oversights in the documentation and intended to work?

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:

* A string or array of strings are treated as literal values with no language associated (unless @language is defined in the context).
* An array of node and/or value objects are treated as they would for any other term.

It’s only the case that the value is an object that it is interpreted as a language map. This is highlighted in 7.5 of the Expansion Algorithm [1]. Note that the keys are not inspected to see if they are reasonable BCP47 language tags, but are simply used as is, including any that may otherwise be a JSON-LD keyword, or are empty.

In general, JSON-LD processing algorithms try to interpret anything reasonably, including keys with a @container or @type defined one way, but used another way within an actual document.

I hope this clarifies the intention and behavior of existing implementations.

Gregg

[1] https://www.w3.org/TR/json-ld-api/#expansion-algorithm

> Playground examples:
> 
> * Single string: http://tinyurl.com/j666mtl <http://tinyurl.com/j666mtl>
> * Array of strings: http://tinyurl.com/hrhwcpb <http://tinyurl.com/hrhwcpb>
> * Object with empty key: http://tinyurl.com/h3ecgzt <http://tinyurl.com/h3ecgzt>
> * Array of string, object: http://tinyurl.com/jbzugno <http://tinyurl.com/jbzugno>
> 
> Thoughts?
> 
> Can we rely on, especially, the three patterns that do the right thing to be understood, despite the spec?
> 
> Rob
> 
> -- 
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305