Consider obsoleting use of blank nodes for properties and "generalized RDF"

[gkellogg]

This is one of the major things that makes JSON-LD out of step with the RDF data model, and it's not clear if the feature is used or valuable. IIRC, the original issue was making it easy to support mapping ad-hoc JSON structures without creating IRIs, but the use of @vocab, and document-relative IRIs for properties would seem to obviate the need for this.

This would likely prohibit the direct use of blank node identifiers in the property position, as well as the mapping of terms to blank node identifiers.

Downsides: another area of potential incompatibility with JSON-LD 1.0. A backwards-compatible solution would be to preserve the feature, but mark it archaic. This might cause warnings to be generated if encountered with a processor running in 1.1 mode.

[ajs6f]

another area of potential incompatibility with JSON-LD 1.0.

Do we actually see this "bnode as property" form used in practice? I can't recall seeing an example, but I haven't seen all that much JSON-LD.

[pjohnston-wiley]

@gkellogg could i request an example? I don't actually understand how the feature would be used? Is this what you mean:

:fred _:b0 :barney .

If so, i don't understand what that would mean and how it would be used practically speaking....

[ajs6f]

@pjohnston-wiley To my (possibly-wrong!) understanding, the issue is that what you show could be written down using JSON-LD 1.0. We are talking about making it illegal in JSON-LD 1.1, because (as you no doubt knew when you wrote it) it's not legitimate RDF 1.1.

@gkellogg Do you think this might be a place to "report forward" to a potential future RDF WG? I don't think that we would have much to say absent any substantive examples.

[pjohnston-wiley]

@ajs6f if that is the case, then i'd totally be supportive of keeping it out of JSON-LD 1.1, but i don't have the history of whether it is possible just because nobody thought to prevent it, or somewhere or another in the mists of time there is/was a legitimate use for it.

[ajs6f]

@pjohnston-wiley Sure, that's exactly why I was asking after examples.

[gkellogg]

@pjohnston-wiley Yes, the ability to create properties as blank nodes was a "feature" of JSON-LD 1.0, and RDF 1.1 created a Generalized Dataset feature, specifically so this could be allowed. The idea was that some JSON developers may not be keen on creating and maintaining vocabularies, and allowing a property to resolve to a blank node would some how make this easier for them, but these blank node identifiers don't survive some of the algorithms, specifically Flattening and ToRdf, and are really of dubious value, IMHO.

@ajs6f Don't know what we would report to a future RDF WG; there are other reasons for Generalized Datasets, and there may be some use cases for blank node properties, but these aren't really explored in JSON-LD.

I'm not aware of any use of this feature in the wild, and obsoleting/removing it in 1.0 could go against our charter, but not sure where the harm is done. A Common Crawl search might be able to find something that uses it, but I doubt it, as they're really not useable for anything other than a source syntax.

The use cases for blank node properties are better handled by document-relative IRIs.

[iherman]

The only place I heard of where bnodes as predicates appear are very technical: there are some more complex OWL deductions where, for "intermediate" steps (if described in terms of triples) they become necessary. To be honest, I do not remember the details, but I would think they are related to terms like inverse properties (where we would say "there is a property that is the inverse of property p").

However, I do not think it is relevant for us. First of all, OWL reasoners rarely (if ever) use RDF as a formalism internally, and serializations like JSON-LD or Turtle are there to encode the data, not the deductions.

[ajs6f]

@gkellogg I guess that would be the report-- that JSON-LD 1.0 made it possible to write down generalized datasets, and no one seemed to care. 🤷‍♂️

[azaroth42]

Proposal: Add an editorial warning to the 1.1 specification that the use of blank nodes as predicates is possible, but that it is deprecated and recommended for removal in a hypothetical JSON-LD 2.0

[ajs6f]

👍, especially since we have yet to come up with an example (unless I missed it in the conversation).

[msporny]

-1, for the following reasons:

• The JSON-LD Charter says nothing about deprecating existing JSON-LD features and this attempts to do exactly that.
• You can't express JSON documents using the RDF data model - full stop. You can do so w/ JSON-LD's data model, which is why this feature was placed in there in the first place. The RDF data model is incapable of expressing JSON as it stands right now.
• We don't have document-relative IRIs for properties, AFAIK?
• JSON-LD's data model does not have to be completely aligned with RDF's data model, there is no requirement for that to be true in the current Charter. If that had been stated, Digital Bazaar would have objected to the charter.

What am I missing?

[azaroth42]

Thanks for the feedback Manu :)

To your points...

• The charter also doesn't say that we can't recommend future removal of features. The (accepted) proposal is an editorial note that the 1.1 WG does not believe that there is sufficient (e.g. any) use of the feature to warrant its definition.
• Given that the empty string is not a valid term (see the closed wontfix issue Revisit empty string as term #12 and precursors), we still can't express arbitrary JSON documents with the JSON-LD model. We couldn't in 1.0 either, with the list of lists issue that has been solved. While this would be a useful parity aspect, we don't have it, regardless of this issue.
• I believe that we do have this feature, see https://w3c.github.io/json-ld-syntax/#using-the-document-base-as-the-default-vocabulary, though I could be misunderstanding the concern?
• It does not, however our guiding principle is to keep the two in as much alignment as possible such that round-tripping is possible.

The new evidence that would overturn the resolution is showing that two organizations are independently using this feature. If it's important, then after 5 years of JSON-LD 1.0, there must surely be two independent uses in the wild? Could you point us to some please?

And again, it's not being removed (that would be a breaking change, which we are indeed not empowered to do), it's being flagged as likely to be removed from the specification in the future unless there's evidence at the time to suggest otherwise.

[gkellogg]

You can't express JSON documents using the RDF data model - full stop. You can do so w/ JSON-LD's data model, which is why this feature was placed in there in the first place. The RDF data model is incapable of expressing JSON as it stands right now.

Document-relative terms support the same use case. This was raised by Kingsley, as he often uses them in his examples and couldn’t in JSON-LD. We added “@vocab”: “” to cause the vocabulary base to be taken as the same as the document base. See json-ld/json-ld.org#488.

JSON-LD's data model does not have to be completely aligned with RDF's data model, there is no requirement for that to be true in the current Charter. If that had been stated, Digital Bazaar would have objected to the charter.

There’s a pretty strong desire by the WG to allow them to be more fully aligned. The primary obstacle to this was the use of Blank Node properties, which the document-relative terms satisfy.

There was no known use of this in the wild, but in any case, the proposal doesn’t remove the feature, just marks it as Obsolete, which indeed, it is. 1.0 documents will continue to work, and 1.1 processors should continue to handle these, but the use is discouraged. The RDF WG did something similar for Reification, IIRC.

There’s a good reason to be able to say that the JSON-LD datamodel is the RDF datamodel, at least formally. Yes, the JSON syntax forms it’s own effective datamodel, but by obsoleting those elements that prevent it from directly corresponding to the RDF datamodel we form a better basis for JSON-LD. IIRC, it was blank nodes as properties that required us to say it is a generalized RDF Dataset, and not simply an RDF Dataset.

Going back to the motivations for allowing blank nodes as properties was an effort to allow easy adoption of JSON-LD by developers not prepared to create vocabulary IRIs to resolve them to. The document-relative term resolution solves exactly the same case, and is consistent with other RDF usage from other syntaxes.