in term definition, the co-occurrence of `@language` and `@type` should be an error

[pchampin]

Consider the following JSON-LD

{
    "@context": {
        "p": {
            "@id": "x:p",
            "@type": "x:datatype",
            "@language": "en"
        }
    },
    "p": "foo"
}

It expands to

[
  {
    "x:p": [
      {
        "@type": "x:datatype",
        "@value": "foo"
      }
    ]
  }
]

The @language is simply ignored.
This is the correct behaviour w.r.t. to the spec. Step 22 of the "Create Term Definition" algorithm explicitly instructs to ignore @language if @type is present.

I consider this as a bug in the spec. The context above makes no sense, and should be rejected with an invalid term definition error (at least, as of JSON-LD 1.2 -- we could preserve the current behaviour if mode is 1.0 or 1.1).

[iherman]

However, isn't so that

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

     "p" : "something"
}

should ideally produce "something"@en? As far as I understand, as of today, the result would be "something" like in your example.

[pchampin]

Meh... Should it produce "something"@en, really?

If we accept that type-coercion and language-coercion are mutually incompatible, and that the most specific rule should apply, then it makes sense to generate "something"^^<whatever-datatype-is-the-value-of-@type> rather than "something"@en. And this is what the spec currently says.

I would rather not make a special case for rdf:langString in the expansion algorithm. I prefer to handle this at the syntax level (as suggested in #682) than at the processing level. If we applied the suggestion in #682, then your example above would raise an invalid value object error. To solve this error, you would need to remove the "@type" from the term definition of "p", which is the correct way to get the result that you want.

Your suggestion is of course more permissive for users (i.e. context designers), so per the priority of constituencies, it may be deemed preferable. But creating special cases in an already quite complex algorithm also makes the algorithm harder to explain to said users, so I would consider that the net benefit is not obvious.

[iherman]

The question may not be whether it is permissive or not but, rather, what exactly the "story" is for internationalized strings. What is the role of the rdf:langString datatype in RDF and, more closely, in JSON-LD, if merely using it in a context effectively destroys its effect? I believe that putting it into the context the way I did in the example, is the perfectly logical way to do it for a lambda user who does not know the details of the API. How would one explain why this is wrong?

[pchampin]

what exactly the "story" is for internationalized strings. What is the role of the rdf:langString datatype in RDF

The story as I see it is that language strings are a special kind of literals, and that their datatype rdf:langString is merely an internal thing of RDF that they should almost ignore. As a matter of fact, when you write (instance) data, not only do you never need to mention rdf:langString, but you actually can not mention it meaningfully. If you try to write "foo"^^rdf:langString in Turtle, or its equivalents in RDF/XML or JSON-LD, trouble will ensue.

Granted, there are situation (outside of writing instance data) when you need to mention rdf:langString:

• writing schemas or shapes: to express that you expect language strings rather than other kinds of literals
• writing SPARQL queries: the datatype function will return rdf:langString for language strings
  but it should be clear (?) from these use-cases that this datatype is mostly an artifact needed to have a homogeneous treatment of the different kinds of literals (which is exactly how this datatype was created, in RDF 1.1).

So, yes, it is a datatype, which in some contexts can be used as any other datatypes (e.g. after rdfs:range), but not in all contexts, because it is a very peculiar datatype (e.g. after ^^ in Turtle, or after "@type": in JSON-LD).

[iherman]

Works for me, @pchampin but I believe it would be useful to add it somewhere in the spec as a note...