Replacement of the diagrams (figure 6 and 8), and their descriptions

[iherman]

Both Figure 6 and Figure 8, and their corresponding description in the text, are incorrect and misleading insofar as to where a graph is used and where it isn't. This PR proposes alternative diagrams for both, as well changes in the corresponding descriptions.

Note that we may have to consider making a distinction in the terminology for a "collection of claims", which has no additional structure, and a "graph", that has a distinct identity in the RDF sense. I know this may lead to some editorial complexity, but the misunderstanding between, on the one hand, just a loose combination of claims (a.k.a. RDF statements) and, on the other hand, a (named) graph in the RDF sense was the source of several confusions in the past, and the figures were just a reflection of that confusion. That being said, the proposed changes are all in an informative section (hence my labeling set to post CR), and maybe there is no need for further changes elsewhere.

(As an aside, the diagrams are deliberately poor in colours, to make them usable for dark mode presentation style.)

Alas! the official, generated preview below is not usable here, because it does not include the diagrams. Please, use the preview on githack instead.

---

Preview | Diff

[iherman]

Note that we may have to consider making a distinction in the terminology for a "collection of claims", which has no additional structure, and a "graph", that has a distinct identity in the RDF sense. I know this may lead to some editorial complexity, but the misunderstanding between, on the one hand, just a loose combination of claims (a.k.a. RDF statements) and, on the other hand, a (named) graph in the RDF sense was the source of several confusions in the past, and the figures were just a reflection of that confusion. That being said, the proposed changes are all in an informative section (hence my labeling set to post CR), and maybe there is no need for further changes elsewhere.

Alternatively... we can continue using the terminology of a graph everywhere (instead of this loose term of "collection of claims"), in which case we can also refer to a "Verifiable Credential Graph" §4.11.1 in the description (and we would have to make this explicit in Figure 6, too). However, I believe that, to make it proper, we have to bring in the terminology of a default graph. I.e., if a JSON-LD document expresses a verifiable credential, then the Verifiable Credential Graph is its default graph (which clearly separates it from the proof graph). If the document expresses a Verifiable Presentation, then the Verifiable Credential Graphs are "created" by virtue of using the verifiableCredential property, whose definition in the @context is such that its value is a named graph (incidentally, these named graphs have all blank nodes as a "name", but that is a detail). Note that we also have then a Verifiable Presentation Graph (which is the default graph of the relevant document).

By using this terminology, things may become clearer. I know we wanted to hide the complexity of RDF Datasets but this seems to backfire, so maybe we have to add this term into the spec.

Note that this makes the definition of proof, when used on VC/VPs, possibly clearer. Indeed:

• The proof property, referred to by an object of type Verifiable Credential, is a proof of the corresponding Verifiable Credential Graph
• The proof property, referred to by an object of type Verifiable Presentation, is a proof of the corresponding Verifiable Presentation Graph, the collection of Verifiable Credential Graphs referred to from the VP, and the Verifiable Credential Proof Graphs, referred to from the aforementioned Verifiable Credentials Graphs.

At this moment, these statements are not clearly defined in the spec imho, which I think is at the core of the discussions in #1248.

@dlongley @msporny

[iherman]

@msporny @dlongley, going along the lines of #1321 (comment) would require more surgery on the VCDM spec. If you agree to go down that route, I am happy to create a separate PR going along those lines (which would supersede this one).

[dlongley]

@iherman,

I do think following comment #1321 (comment) is probably best because it clears up some of the technical details here and highlights how we're relying on default graphs for isolation / separation in documents that either express VPs or VCs.

[iherman]

@iherman,

I do think following comment #1321 (comment) is probably best because it clears up some of the technical details here and highlights how we're relying on default graphs for isolation / separation in documents that either express VPs or VCs.

Ok. I will try to come up with a replacement PR next week.

[iherman]

Closing this, without merge, in favor of #1326