NaturalLanguageValue should be languaged typed string

[elf-pavlik]

reported by @pfps via: http://lists.w3.org/Archives/Public/public-vocabs/2014Nov/0025.html

I also noticed that NaturalLanguageValue has the wrong superclass - it should be languaged typed string.

[jasnell]

Example?

[pfps]

xsd:string instances don't have language tags, which appear to be a very important aspect of the values of NaturalLanguageValue. All (or almost all) of the examples in the documentation include language tags for values of NaturalLanguageValue, which makes them not be instances of xsd:string.

[jasnell]

Is there an alternative type they should be mapped to?

[elf-pavlik]

as I understand http://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal it recommends http://www.w3.org/1999/02/22-rdf-syntax-ns#langString but i think then it requires string to have language tag

[pfps]

Well, yes, and language tagged string has to have a language tag, but isn't that the requirement for NaturalLanguageValue?

[jasnell]

No, the language context is optional... using displayName as an example, the following would be legal:

{
  "@context": "http://asjsonld.mybluemix.net",
  "displayName": "An example"
}

{
  "@context":  [
    "http://asjsonld.mybluemix.net", 
    {"@language": "en"}
  ],
  "displayName": "An example"
}

{
  "@context": "http://asjsonld.mybluemix.net",
  "displayName": {
    "@value": "An example",
    "@language": "en"
  }
}

{
  "@context": "http://asjsonld.mybluemix.net",
  "displayName": {
    "en": "An example", 
    "fr": "Un exemple"
  }
}

In the first, "displayName" is just a string, without any language tag. In the remaining, the "displayName" value becomes a language-tagged string.

To simplify the spec, I have proposed removing the "Natural Language Value" construct (which is a carryover from the pre-JSON-LD-based serialization. Doing so ought to greatly simplify things but it would still be necessary to get this right in the vocabulary.

Specifically, the properties "title", "summary", "content" and "displayName" can be either xsd:string || rdf:langString.

[pfps]

Hmm. Then what language is the string supposed to be interpreted in if the language tag is missing?

peter

On 11/03/2014 07:44 PM, James M Snell wrote:

No, the language context is optional... using displayName as an example, the following would be legal:

{ "@context":"http://asjsonld.mybluemix.net", "displayName":"An example" }

{ "@context": [ "http://asjsonld.mybluemix.net", {"@language":"en"} ], "displayName":"An example" }

{ "@context":"http://asjsonld.mybluemix.net", "displayName": { "@value":"An example", "@language":"en" } }

{ "@context":"http://asjsonld.mybluemix.net", "displayName": { "en":"An example", "fr":"Un exemple" } }

In the first, "displayName" is just a string, without any language tag. In the remaining, the "displayName" value becomes a language-tagged string.

To simplify the spec, I have proposed removing the "Natural Language Value" construct (which is a carryover from the pre-JSON-LD-based serialization. Doing so ought to greatly simplify things but it would still be necessary to get this right in the vocabulary.

Specifically, the properties "title", "summary", "content" and "displayName" can be either xsd:string || rdf:langString.

— Reply to this email directly or view it on GitHub https://github.com/jasnell/w3c-socialwg-activitystreams/issues/45#issuecomment-61589557.

[jasnell]

The language context would be considered to be "undefined".

(Note that backwards compatibility with Activity Streams 1.0 is being considered here. AS 1.0 does not have any notion of language context and there are existing documents that do not include any language tagging.)

[jasnell]

Covered by current editor's draft