toRdf/0118 fails in JSON-LD 1.1

[gkellogg]

Since we added a provision in Create Term Definition that for simple terms to be used as prefixes, they need to end in a genDelim character, toRdf/0118 does not render the same results.

The relevant part of this test is the following:

{
  "@context": {"term": "_:term", "termId": { "@id": "term", "@type": "@id" }},
  "termId": "term:AppendedToBlankNode"
}

This previously expanded to the following:

[{
  "_:term": [{"@id": "_:termAppendedToBlankNode"}]
}]

Now it generates the following:

[{
  "_:term": [{"@id": "term:AppendedToBlankNode"}]
}]

This is because the new test does not use "term" as a prefix, so it's treated as a scheme.

We could either update the algorithm to allow blank node terms to be used as prefixes, or make this a 1.0-only test. As the general trend for us is to deprecate blank node terms, this might be the way to go. Note that a workaround would be to make it an expanded term definition with @prefix set to true. But, this might affect contexts such as that used by Activity Streams, so the safest thing would be to update 16.6 as follows:

If term contains neither a colon (:) nor a slash (/), simple term is true, and if the IRI mapping of definition ends with a URI gen-delim character, or is a blank node identifier, set the prefix flag in definition to true.

We could add another note about the use of blank node properties as being obsolete.

[pchampin]

I think it is risky to introduce a backward incompatibility, so +1 to to @gkellogg 's solution.

[dlongley]

Using a blank node as a prefix sounds like total nonsense to me. I'm not even sure what the use case would have ever been. I'd prefer to make this a JSON-LD 1.0-only test.

[gkellogg]

Note that this is unlike the Activity Streams use of @vocab: _:, and there is no known use of terms defined as blank nodes being used as prefixes; it was IIRC just a consequence of the 1.0 algorithm, so I think we can make it 1.0 only and have virtually zero chance of affecting any current usage.

[pchampin]

there is no known use of terms defined as blank nodes being used as prefixes; it was IIRC just a consequence of the 1.0 algorithm

in that case, +1 to marking it as 1.0 only and banning bnode prefixes from 1.1.

[pchampin]

We will probably need to reconsider this, as the WG decided to not break this 1.0 feature... The rationale was that, if the feature had tests written for it, it is hard to argue that it was unintentional or not thought through... Not that we enjoyed coming to that conclusion :-/