Property value of Natural Language property should return all language values

[gkellogg]

Currently, the property value for a Natural Language property, such as title returns only values for the default language. This should probably return all values.

The proposed change is:

The property value for natural language property is an object whose properties are language codes and where the values of those properties are arrays (see Language Maps in [[!JSON-LD]]).

As a property value is taken after metadata is merged natural language properties will already be in this form, and it is compatible with JSON-LD language maps (other than und).

[gkellogg]

See https://lists.w3.org/Archives/Public/public-csv-wg/2015Feb/0000.html for discussion.

It is not really clear from the definition of the property value. I presume the intention is that the property value for B is

["My title", "Mon titre"]

maybe it should be

[{ "en" : "My title" }, { "fr" : "Mon titre }]

ie, some sort of a canonical value...

My interpretation may vary well be faulty, and the property value of a natural language property should include all titles in all languages. On reflection, I think this is the correct interpretation, and the property value should include all defined values in all languages.

We also need to consider precisely what atomic properties make use of @language, which is defined to be the default language of properties in the document. The only one which could possible make sense is name, which I've taken to be a string without language, but maybe it should get the language of @language or the title which is promoted. Given how it's used, I don't think having a language for name is useful, but we should be explicit. In that case, the only thing @language applies to is common properties and title, where it is a string or array of strings.

Maybe the definition of property value should be something like:

[[[
The property value for natural language property is an array of objects, each object having a single key/value pair of the form

{ [language code] : [String] }

The objects are created from the original definition as follows:

• if the metadata value is a string, the language code in the resulting object is either the value of "@langauge", if it exists, or "und" otherwise
• if the metadata value is an array, the language code for each resulting objects is either the value of "@langauge", if it exists, or "und" otherwise
• if the metadata value is an object, the array are the constituent key/value pairs, after possibly flattening values that are themselves arrays with the common key
  ]]]

(this obviously needs refinement). With this definition, the second alternative below seems to work well.

WDYT?

Why wouldn't it just be the same representation as the merged value?

[[[ an object whose properties are language codes and where the values of those properties are arrays]]]

This has the advantage of being equivalent to the JSON-LD representation. I think this makes more sense than using yet another representation involving arrays of objects with tags. Since all metadata used for extracting property values is the result of a merge, that is the most natural representation to use. So, I'd be inclined to go with the following:

[[[
The property value for natural language property is an object whose properties are language codes and where the values of those properties are arrays (see Language Maps in [[!JSON-LD]]).
]]]

Given that when processing all metadata is the result of a merger (possibly with the default metadata used for extracted embedded metadata), it shouldn't be necessary to re-define the procedure for normalizing values to the object form.

[gkellogg]

Note, this is included in PR #96 due to merge conflicts.

[JeniT]

I think we need to work through all of this at the F2F, with a board. I can't follow the logic above.

[JeniT]

Discussed briefly at Feb F2F, all OK.