Address normative concept of VerifiableCredentialGraph

[OR13]

See the original comment here: #1236 (comment)

The word "envelop" is being used here, in a way that aligns with "VerifiablePresentation".

I find the concept of "VerifiableCredentialGraph" confusing, and note that it does not occur even once in the current TR.

https://github.com/search?q=repo%3Aw3c%2Fvc-data-model%20VerifiableCredentialGraph&type=code

I prefer to remove the term, since it can only lead to more confusion.

If the term is providing value, I prefer to unify that value with "VerifiablePresentation", but would need to know more about how it actually works, to even propose a path to that.

[OR13]

In the original comment, @iherman wrote:

How is it different from: the former is the "envelope" that contains the latter. Just as the envelope is not the same as what it contains, the VerifiableCredentialGraph is different from what it contains, i.e., a VerifiableCredential. This differentiation is crucial for, e.g., the usage of the RDFC 1.0 algorithm.

Can someone elaborate further on this?... seems like changes here would potentially be breaking, I'd like to understand why that is a good thing / bad thing.

[iherman]

I find the concept of "VerifiableCredentialGraph" confusing, and note that it does not occur even once in the current TR.

https://github.com/search?q=repo%3Aw3c%2Fvc-data-model%20VerifiableCredentialGraph&type=code

Indeed, it is not explicitly in the spec. But the concept is already there in the context file:

"verifiableCredential": {
          "@id": "https://www.w3.org/2018/credentials#verifiableCredential",
          "@type": "@id",
          "@container": "@graph"
        },

Ie, the fact that the value of a verifiableCredential is a graph and not a VerifiableCredential. That aspect must be expressed in the vocabulary. Speaking bluntly, the vocabulary specification in the 1.1 version for that term was a bug.

Maybe it is worth referring to the concept of RDF graphs (a.k.a. datasets) in the RDF 1.1 spec.

I prefer to remove the term, since it can only lead to more confusion.

I would -1 to remove the "concept" from the vocabulary. I am fine trying to find a different name.

[iherman]

Admin note: this issue was discussed and decided upon a long time ago in issue #770, and a resulting PR in #771 (back in 2021!). I have made the mistake (due to my failing memory) to reopen the same issue a year later in #907 and the general concept was also discussed in #881. All these issues and PR-s have been closed, and the current vocabulary is around for at least a year. Is there a reason for reopening the same issue again?

[OR13]

Ie, the fact that the value of a verifiableCredential is a graph and not a VerifiableCredential. That aspect must be expressed in the vocabulary. Speaking bluntly, the vocabulary specification in the 1.1 version for that term was a bug.

Yes, I thought these were related.

I guess I am still confused on the difference between a "graph" and a "JSON-LD object with a context".

Especially given this:

• https://w3c.github.io/vc-data-model/#dfn-graphs
• https://w3c.github.io/vc-data-model/#dfn-credential

[OR13]

Admin note: this issue was discussed and decided upon a long time ago in issue #770, and a resulting PR in #771 (back in 2021!). I have made the mistake (due to my failing memory) to reopen the same issue a year later in #907 and the general concept was also discussed in #881. All these issues and PR-s have been closed, and the current vocabulary is around for at least a year. Is there a reason for reopening the same issue again?

Yes, in v2... both the context and vocabulary are now normative... and I suspect based on the issues linked that people still don't understand the implications of this on verifiers.

[iherman]

Admin note: this issue was discussed and decided upon a long time ago in issue #770, and a resulting PR in #771 (back in 2021!). I have made the mistake (due to my failing memory) to reopen the same issue a year later in #907 and the general concept was also discussed in #881. All these issues and PR-s have been closed, and the current vocabulary is around for at least a year. Is there a reason for reopening the same issue again?

Yes, in v2... both the context and vocabulary are now normative...

I do not think that declaring them to be normative makes a change in this respect. Actually, because the vocabulary is normative, this bug MUST be handled (and has been handled in the v2 version of the vocabulary), whereas v1 could be published with a buggy vocabulary.

[OR13]

@iherman we can make breaking changes in v2... fixing bugs should be on the table, not under the rug : )

It's possible the working group agrees, that the current behavior / bug is ok... its possible they want to fix it.

How do we "handle this bug", what does that mean?

[iherman]

I do not understand your remark, @OR13. This issue was raised, discussed, and closed. Long time ago.

At this moment, there is no bug. The vocabulary has been handled/fixed a while ago.

You are questioning the underlying concept (a.k.a. the fact that verifiableCredential is labeled as being a graph container in the context file) which has been known for a long time, and I do not see any new fact on the table that requires reopening this.

[OR13]

@iherman concretely, I would like to see this part of the vocabulary and the related parts of the TR improved... substantially:

- id: verifiableCredential
    defined_by: https://www.w3.org/TR/vc-data-model-2.0/#defn-verifiableCredential
    label: Verifiable credential
    domain: cred:VerifiablePresentation
    range: cred:VerifiableCredentialGraph
    comment: The value of this property identifies a <a href="#VerifiableCredentialGraph">Verifiable credential graph</a>. (Informally, it indirectly identifies a <a href="#VerifiableCredential">Verifiable credential</a> contained in a separate graph.)

The new information on the table is that I am asserting that it is confusing, and not good enough now that the vocabulary is normative.

1. the label should be updated.
2. the comment should refer to the TR, and explain the usefulness of "separate graphs".
3. ideally the range can be adjusted to not introduce a new concept... For example, would it be equally precise to say the range is "Credential" (related to the Abstract class issue with "VerifiableCredential") ?

In short, I don't think the current vocabulary meets the standard for publication, and especially this term, needs improvement.

Looks at the rest of the vocabulary, I can see several other issues... I will file some PRs to correct them.

[OR13]

https://github.com/w3c/vc-data-model/pull/1241/files

What is the utility of label ? It seems to not provide a lot of value in the current vocabulary... How can it be improved?

[iherman]

@iherman concretely, I would like to see this part of the vocabulary and the related parts of the TR improved... substantially:

- id: verifiableCredential
    defined_by: https://www.w3.org/TR/vc-data-model-2.0/#defn-verifiableCredential
    label: Verifiable credential
    domain: cred:VerifiablePresentation
    range: cred:VerifiableCredentialGraph
    comment: The value of this property identifies a <a href="#VerifiableCredentialGraph">Verifiable credential graph</a>. (Informally, it indirectly identifies a <a href="#VerifiableCredential">Verifiable credential</a> contained in a separate graph.)

The new information on the table is that I am asserting that it is confusing, and not good enough now that the vocabulary is normative.

1. the label should be updated.

I welcome any specific proposal.

2. the comment should refer to the TR, and explain the usefulness of "separate graphs".

I leave this to @msporny, @dlongley, @awoie or others who are deeply involved with the VC details on the matter. The comment field can refer to any specific text of course.

3. ideally the range can be adjusted to not introduce a new concept... For example, would it be equally precise to say the range is "Credential" (related to the Abstract class issue with "VerifiableCredential") ?

The "new concept", as you call it, is absolutely necessary, because an RDF Graph is not the same as a Class. Dropping this re-introduces the bug in v1. And, I repeat, it is not a "new concept" at all: it is a proper formulation of the fact that the verifiableCredential property (or the proof property in the security vocabulary, for that matter) are defined as graph containers. That has always been the case ever since I looked at the verifiable credentials specification. Removing this feature is a hugely breaking change.

Unless you define "Credential" as a Graph and not a Class, your proposal will not fly either.

cc @pchampin

[TallTed]

What is the utility of label?

It's a human-facing label for the machine-facing URI. Feed the ontology to a visual editor, and you should see the utility. Instead of a bunch of nodes and edges that are all visually labeled with URIs, you'll see them labeled with labels.

[OR13]

Perhaps we can elaborate on the value of "VerifiableCredentialGraph" in the processing the vc-data-model as JSON-LD section? cc @msporny

[OR13]

It's a human-facing label for the machine-facing URI. Feed the ontology to a visual editor, and you should see the utility. Instead of a bunch of nodes and edges that are all visually labeled with URIs, you'll see them labeled with labels.

thanks @TallTed makes sense that we would then strive to make labels more accurately describe the term URIs, so adding the word "graph" here... makes sense... https://github.com/w3c/vc-data-model/pull/1241/files#diff-dfe00db9d510a45f71289312990ee36df870f36c02094551bfba625dcd0d8e96R155

[iherman]

The issue was discussed in a meeting on 2023-08-15

• no resolutions were taken

View the transcript

2.9. Address normative concept of VerifiableCredentialGraph (issue vc-data-model#1240)

See github issue vc-data-model#1240.

Brent Zundel: next issue is 1240. raised by Orie today. already touched on briefly in other conversations. what does it entail? before or after CR?

Orie Steele: don't think we'll make any changes to this part. Ivan thinks it will be a breaking change to adjust this property. It is a graph identifier not a predicate or class. Probably few people in the WG understand this. Important to separate this concept.
… RDF experts are excited about this property. struggling to see how anyone benefits from it. would be good to focus on w.r.t explaining the value of the data model being JSON-LD.

Brent Zundel: before or after CR?

Orie Steele: if we were to remove, that would be a breaking normative change. going to assume no one in the WG understands it well enough to have it removed. should be post CR with the assumption that no one really understands the value of processing the data model with this term.
… maybe the value of JSON-LD processing is post-CR and Manu shouldn't write that section now. pretty confused of the value of the data model as RDF; this issue would help with it.

Manu Sporny: for the same reason a VP can have multiple VCs, and each VC is in a separate bucket, this is so that we can talk about the claims in each bucket separately. talk about the bucket itself. who made claims, statements. to do that we need to contain the data in something. that's what the graph is there to do.

Orie Steele: sounds like we are well on our way to describing the value of JSON-LD, and it has something to do with RDF buckets : ).

Manu Sporny: when you have two people say things we put each one of them in a bucket. JSON does not have this concept, you would have to create a bespoke data format to do that. RDF/LD have it built in automatically. benefit of using a graph based data model = buckets.

Brent Zundel: based on Orie's question and your response, see this as a sub-issue of the value of JSON-LD issue you're already going to attempt. labeling as before CR, since the other one is too.

Dmitri Zagidulin: I'm kind of failing to see what this issue has to do with the JSON-LD issue...

Manu Sporny: would that address your concern?

Orie Steele: yes would help with this property and the proof container - two places with the container syntax/context. these sections cry out for 'what is the value of this'. should be language around those pieces. left a comment on the previous issue asking you to comment on this issue.

Orie Steele: dmitriz you are probably struggling to see the value of JSON-LD then, and you are in good company... hence our need to describe that value as we have already described how you don't need it when processing the data model as JSON.

[iherman]

The issue was discussed in a meeting on 2023-08-15

• no resolutions were taken

View the transcript

1.8. Vocabulary fixes (pr vc-data-model#1241)

See github pull request vc-data-model#1241.

Brent Zundel: next PR is 1241 vocab fixes. seems straightforward. Orie do you want to speak to it?

See github issue vc-data-model#1240.

Orie Steele: copy-paste bug in the render method. question I had asked to Ivan on the value of the label property. related to issue linked (1240). slightly improves our vocabulary.

[iherman]

Let me try to explain one of the reason why RDF Datasets come into the picture. In what follows I will only use diagrams depicting RDF Graphs; JSON-LD, which is just a syntactic sugar for the RDF statement, tend to make things more difficult to follow in my experience. (Also, although I use VC examples, do not get hooked on details in case it is not exactly what is expected for VCs.)

Consider the simple RDF Graph below:

A VP points at two, independent, Verifiable Credentials. This is the kind of (RDF) graph one would get if the value of the verifiableCredential property pointed directly at a VerifiableCredential instance. As a next step, consider the situation where an implementation wants to sign the two credentials independently of one another. To go through the canonicalizaton-hash-etc. steps, the implementations must, first, gather all the nodes and edges that belong to the first credential (the green blobs thus, together with the corresponding edges) and, separately, the same for the second credential (i.e., the blue blobs). This is of course doable, but it is a pain if there are many green, respectively blue, blobs; essentially, the implementation must have a graph traversal algorithm at disposal. Of course, RDF environments (e.g., triple store like Virtuoso) have tools to do that for you using either proprietary query languages, or standards like SPARQL, but even with those it is not really obvious, and not efficient either. It would be much more efficient if the data carried the information about having two independent VCs (an information that the application has but gets lost during the translation to the data model).

Here is where the extra abstraction of separate RDF Graphs comes in, based on the concept of RDF Datasets. The notion of identifiable RDF Graphs gives you a way to separate the various (sub-)graphs at the data modeling and creation level, yielding the alternative realization below:

What happens here is that the application has the possibility to declare up front that the green, respectively blue, blobs belong together, they are part of what is referred to as separate RDF Graphs (ie, entities with their own identifier referring to a bunch of RDF statements). The verifiableCredential refers to the individual RDF Graphs. No separate graph traversal algorithm is needed and, needless to say, query languages like SPARQL have a way to get all the relevant RDF triples with one single (and simple) query, so it is way more efficient.

The current VCDM model implements the second approach. The practical translation of all this is that (a) the JSON-LD context defines verifiableCredential to be a "graph container", which is a fancy term to say that it refers to a separate Graph and not to what the nodes it contains, and (b) the vocabulary gives a proper model for this in the ontology using the VerifiableCredentialGraph notion.

(As far as I know, the first versions of VCs were defined in terms of the first example, and it is the practical implications like the ones I described above that led to the second approach. But I may be wrong, I was not around in VC land at that time...)

I hope this helps.

---

Truth must be said: the approach we have chosen to model the notion of graph with a separate class, i.e., VerifiableCredentialGraph in the vocabulary, is not ideal; that is because the current RDF toolbox misses a dedicated tool (@pchampin, is this something for RDF 1.2?). Hence, the necessity to add some textual, i.e., English prose, to the specification of the class instance in the vocabulary. The reason is that RDF Datasets is a relatively new kid on the block, compared to the rest, and was the subject of epic discussions on how to get it right. But what we have there is precise enough for our purposes I believe.

[OR13]

This picture is good, if it had proofs in it, it would be even better since they are also treated as "separate graphs".

In my experience, or perhaps in the limiting RDF tooling I have been exposed too... you don't ever see the edges that connect the "separate graphs"...

So if you convert a VP with a single VC, where each have a single proof, you get disconnected graphs:

1. the VP graph
2. the first credential
3. the proof for the first credential
4. the proof for the vp

This is super confusing for first time consumers of RDF, it might even cause people to prefer to NOT use RDF.

Lets look at a real world example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "http://university.example/credentials/1872",
    "type": ["VerifiableCredential", "ExampleAlumniCredential"],
    "issuer": "https://university.example/issuers/565049",
    "validFrom": "2010-01-01T19:23:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": "Example University"
      }
    },
    "proof": {
      "type": "DataIntegrityProof",
      "cryptosuite": "eddsa-2022",
      "created": "2023-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://university.example/issuers/565049#key-1",
      "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
    }
  }],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-2022",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "proofValue": "zqpLMweBrSxMY2xHX5XTYV8nQAJeV6doDwLWxQeVbY4oey5q2pmEcqaqA3Q1gVHMrXFkXM3XKaxup3tmzN4DRFTLV"
  }
}

From https://json-ld.org/playground

The "golden circles" ... how come they don't show up in the n-quads?

<did:example:c276e12ec21ebfeb1f712ebc6f1> <https://www.w3.org/ns/credentials/examples#name> "Example University" _:b3 .
<did:example:ebfeb1f712ebc6f1c276e12ec21> <https://www.w3.org/ns/credentials/examples#alumniOf> <did:example:c276e12ec21ebfeb1f712ebc6f1> _:b3 .
<http://university.example/credentials/1872> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> _:b3 .
<http://university.example/credentials/1872> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential> _:b3 .
<http://university.example/credentials/1872> <https://w3id.org/security#proof> _:b4 _:b3 .
<http://university.example/credentials/1872> <https://www.w3.org/2018/credentials#credentialSubject> <did:example:ebfeb1f712ebc6f1c276e12ec21> _:b3 .
<http://university.example/credentials/1872> <https://www.w3.org/2018/credentials#issuer> <https://university.example/issuers/565049> _:b3 .
<http://university.example/credentials/1872> <https://www.w3.org/2018/credentials#validFrom> "2010-01-01T19:23:24Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:b3 .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiablePresentation> .
_:b0 <https://w3id.org/security#proof> _:b1 .
_:b0 <https://www.w3.org/2018/credentials#verifiableCredential> _:b3 .
_:b2 <http://purl.org/dc/terms/created> "2018-09-14T21:19:10Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:b1 .
_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> _:b1 .
_:b2 <https://w3id.org/security#challenge> "1f44d55f-f161-4938-a659-f8026467f126" _:b1 .
_:b2 <https://w3id.org/security#cryptosuite> "eddsa-2022" _:b1 .
_:b2 <https://w3id.org/security#domain> "4jt78h47fh47" _:b1 .
_:b2 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#authenticationMethod> _:b1 .
_:b2 <https://w3id.org/security#proofValue> "zqpLMweBrSxMY2xHX5XTYV8nQAJeV6doDwLWxQeVbY4oey5q2pmEcqaqA3Q1gVHMrXFkXM3XKaxup3tmzN4DRFTLV"^^<https://w3id.org/security#multibase> _:b1 .
_:b2 <https://w3id.org/security#verificationMethod> <did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1> _:b1 .
_:b5 <http://purl.org/dc/terms/created> "2023-06-18T21:19:10Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:b4 .
_:b5 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> _:b4 .
_:b5 <https://w3id.org/security#cryptosuite> "eddsa-2022" _:b4 .
_:b5 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:b4 .
_:b5 <https://w3id.org/security#proofValue> "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"^^<https://w3id.org/security#multibase> _:b4 .
_:b5 <https://w3id.org/security#verificationMethod> <https://university.example/issuers/565049#key-1> _:b4 .

How do I automatically generate a picture that "connects the disconnected RDF subgraphs"... using some off the shelf tooling?

When we implemented a way to import JSON-LD into Neo4j, we had to convert these structures by hand, because the graph that the n-quads build automatically... does not come with the arrows in your picture... because as you have said... they are treated as "separate information graphs".

_:b0 <https://www.w3.org/2018/credentials#verifiableCredential> _:b3 .

• _:b0 is a VerifiablePresentation with no id.
• _:b3 contains a VerifiableCredential is id http://university.example/credentials/1872

_:b0 <https://w3id.org/security#proof> _:b1 .

• _:b0 is a VerifiablePresentation with no id.
• _:b1 contains a DataIntegrityProof with no id.

My understanding is that contains does not produce edges... this leads too disconnected subgraphs.

We had to write custom code to reconnect them, in order to make the picture you have shared... it did not come for free from using RDF.

• https://github.com/transmute-industries/transmute/tree/main/examples/neo4j#presentation
• https://github.com/transmute-industries/transmute/blob/main/src/api/rdf/jsongraph.ts#L67
• https://github.com/transmute-industries/transmute/blob/main/src/api/rdf/jsongraph.ts#L143

[iherman]

@OR13

or perhaps in the limiting RDF tooling I have been exposed too... you don't ever see the edges that connect the "separate graphs"

yes, the tools you are looking at are limited :-( None of the (generally limited) graphical representation tools for RDF that I know of are prepared for the representation of RDF Datasets. I am not sure what tool the JSON-LD Playground use (@davidlehn or @dlongley should know); I suspect that the tool is simply not prepared to represent n-quads, but only n-triples. The picture you reproduce is simply wrong.

The n-triples statements that you reproduce are, on the other hand, correct.

_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://...#VerifiablePresentation> .
…
_:b0 <https://www.w3.org/2018/credentials#verifiableCredential> _:b3 .

note that these statements have no 4th element, because they are part of the "default" graph. They show that _:b0 identifies the VP, and _:b3 identifies the verifiable credential graph that is referred to from the VP. Then

<http://university.example/credentials/1872> <http://...#type> <https://...#VerifiableCredential> _:b3 .

shows that there is a Verifiable Credential, with the id set to .../1872, and which is in that graph (by virtue of the fourth entry of the n-quad). Everything is fine, and exactly along the line of the vocabulary as specified. The concept of VerifiableCredentialGraph, that started this issue, is just there to characterize _:b0 in the vocabulary. Finally, the "golden circle" in the diagram you reproduced _4459402 is, I believe, just... junk.

I do not know whether there are tools that could be used to visually show an RDF Dataset. @pchampin or @TallTed might know, I am not active in the field anymore.

As for your remark on Neo4j: with all my respect to Neo4j, it has never been defined as an RDF Database. If you only care about the pure JSON structure, then it may be perfectly fine. But then you do not care about the n-quads, nor do you care about the details of the vocabulary. On the other hand, if you do care about the n-quads level of things, then that tool is not appropriate for the purpose. I do not know Neo4j well enough to comment on it.

[OR13]

Neo4j does have an RDF plugin, but it's not available in their cloud instances, and does not seem to be popular or growing in customers.

Last time I ran it on N-Quads (it errors trying to import compact JSON-LD), it produced disconnected graphs.

This started my journey to try to create a picture like the one you shared.

As far as I can tell, you never get that picture unless you add the "missing edges" between the blank nodes that represent the separate graphs.

The more separate graphs you have in a JSON-LD object (deep nesting) the harder it gets to figure out how to add those edges... while the json representations make these relationships obvious, it's been my experience you loose them after converting to RDF, because blank nodes are not globally unique, and no rdf library I have used knows how to connect none globally unique nodes consistently.

I think the examples in the core spec are slightly misleading on the point, since they blend the json view of the data with parts of the RDF view, that make it seem like some relationships are present / preserved that are not.

At any rate, if this disconnected graph is expected behavior and it's stable, we can work around it. I just wanted to be sure it was not bugged, since it's not intuitive, at least for me.

[iherman]

I think the examples in the core spec are slightly misleading on the point, since they blend the json view of the data with parts of the RDF view, that make it seem like some relationships are present / preserved that are not.

I am happy to look at the examples in the VCDM spec, but that is definitely a "during CR" action.

At any rate, if this disconnected graph is expected behavior and it's stable, we can work around it. I just wanted to be sure it was not bugged, since it's not intuitive, at least for me.

Maybe the discussion helped a bit. Once one gets used to RDF Datasets it is actually fairly intuitive. But our experiences are different, obviously...

Can we close the issue? Also, can you approve #1236 to, eventually, merge it?

[OR13]

Ideally we can close this issue after commenting on the value of importing VerifiableCredentials as separate graphs when importing a verifiable presentation... I would bet some language in the related PR that @msporny is raising will address this... I suggest we leave it open until then, I can help add text to that PR in case this is not addressed in the initial attempt.

[iherman]

The issue was discussed in a meeting on 2023-09-06

• no resolutions were taken

View the transcript

4.3. Address normative concept of VerifiableCredentialGraph (issue vc-data-model#1240)

See github issue vc-data-model#1240.

Manu Sporny: I am on the hook for this PR.

Orie Steele: +1 Manu, its also related to the vocab vs spec.

Manu Sporny: yep ^.

Manu Sporny: which I am ready to work on, given the prior discussion about vocab vs spec.

[msporny]

PR #1280 has been raised to address this issue. This issue will be closed once PR #1280 has been merged.

[msporny]

PR #1280 has been merged, closing.