msporny
commented
1 year ago @iherman and @dmitrizagidulin wrote:
I am bothered by the terminology used around "data models"
I have raised issue #165 to track this concern. I understand the trepidation, but also didn't want to create a big debate around what the data model is for data integrity. One could argue that it's a version of INFRA that maps cleanly to both JSON-LD and JSON... or, one could argue that it's JSON-LD with special rules if you don't want to use a JSON-LD processor and just operate using JSON tooling. Both of those statements are true, and what we're probably missing is general guidance around "Gaining the benefits of JSON-LD without using JSON-LD Processors."
How useful it is to go into these depths is questionable from an implementer standpoint... do they need an answer to this question to write an implementation that is conformant? No, I don't think they do. :)
Sure, it might be helpful to some implementers to know that the mental model (data model) sticks together... but trying to convey that in the conformance section, or having to repeat it in every specification that uses JSON-LD is probably not helpful. This should probably become a section in the JSON-LD specification (the fact that you can gain many of the benefits of JSON-LD w/o doing full blown JSON-LD (or RDF) processing.
In any case, I don't know what to write/change and need some help doing so. Let's discuss in issue #165 and, if we have a flash of clarity, then we can raise another PR to modify this section. In the meantime, we don't have /any/ conformance classes, so I'm going to merge this PR (since no one is objecting, though there is uneasiness around the "data model"). We can continue the discussion in #165.
This PR attempts to address issue #159 by defining the conformance classes that are relevant to the specification.
Preview | Diff