value object with `"@type": "rdf:langString"`

[pchampin]

Consider the following:

{
  "x:p": {
    "@value": "foo",
    "@type": "http://www.w3.org/1999/02/22-rdf-syntax-ns#langString"
  }
}

It is currently a valid JSON-LD document, even though it corresponds to an invalid RDF graph (because a literal with datatype rdf:langString but no language tag is not allowed in the abstract data model.
In fact, this causes an ambiguity in the toRdf algorithm, which does not tell you what to do with this pathological case, and implementations diverge.

• jsonld.js simply "eats" the datatype, turning it implicitly into (permalink)
• sophia faithfully produces "foo"^^rdf:langString (permalink), but then refuses to parse the resulting n-quads (permalink)
• PyLD raises an error

Proposed solution: we should refine the definition of value object to forbid @type to have value http://www.w3.org/1999/02/22-rdf-syntax-ns#langString (and, eventually, http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString).
Accordingly, the Expand algorithm should raise an "invalid value object" error when it is lead to create such an object (e.g. via IRI expansion and/or type coercion).

[iherman]

I presume you meant http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString …

[iherman]

But, I presume,

{
  "x:p": {
    "@value": "foo",
   "@language": "en"
    "@type": "http://www.w3.org/1999/02/22-rdf-syntax-ns#langString"
  }
}

should be valid. In other words, type coercion should not apply to this case (see #681)

[pchampin]

I presume you meant http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString …

yes, thanks. I edited my post to fix it.

But, I presume,

{
  "x:p": {
    "@value": "foo",
   "@language": "en"
    "@type": "http://www.w3.org/1999/02/22-rdf-syntax-ns#langString"
  }
}

should be valid.

It is currently not valid: the value of x:p is a value object (because it has a @value), and so it must not contain @type and @language at the same time.

We might want to allow them to co-exist only if @type has the appropriate value, but it would complicate the definitions with no clear added value. It would be like asking Turtle to accept "chat"@en^^rdf:langSTring.

In other words, type coercion should not apply to this case (see #681)

Well, type coercion is out of the picture here, because we are considering the expanded form. This issue is orthogonal to #681.

[pchampin]

Well, type coercion is out of the picture here

and I realize the title of this issue was misleading in that respect. The reason being that it started with an idea, and evolved into something different while I was writing the issue. The new title is more appropriate now (and we should probably move this to the json-ld-syntax repo, btw).