Error in the (RDF) vocabulary of the VC Data Model?

[iherman]

(This issue was triggered by #905)

I believe there is discrepancy between the official VC vocabulary and the VC @context file (both v1 and the proposed v2).

The (turtle version of) the vocabulary defines the verifiableCredential as follows (I've removed some irrelevant triples):

cred:verifiableCredential a rdf:Property;
  rdfs:domain cred:VerifiablePresentation;
  rdfs:range cred:VerifiableCredential;
  .

The problem I have is with the rdfs:range definition. In my reading, both per the definition of the property in the specification and the aforementioned @context files, the range of the property is an RDF Graph whose single top level resource is of type cred:VerifiableCredential and not a Resource with the type cred:verifidableCredential (which is what the range definition claims).

To make it very specific, look at the playground example. The relevant triples generated by the playground are (I have taken out some triples and shortened the URLs to simplify things):

<http://example.edu/credentials/1872> rdf:type cred:VerifiableCredential _:b1 .
<http://example.edu/credentials/1872> cred:credentialSubject <did:example:ebfeb1f712ebc6f1c276e12ec21> _:b1 .
<http://example.edu/credentials/1872> cred:issuer <https://example.edu/issuers/565049> _:b1 .
_:b0 cred:verifiableCredential _:b1 .

The important triple is the last one, which corresponds to the statement:

  "verifiableCredential": [{...}]

The object of the triple is (the reference of) an rdf graph (with a identifier set to _:b1). This graph has some triples referring to <http://example.edu/credentials/1872> (referring to the id setting in the example) and, indeed, these include a triple setting the .../1872 resource to be of type cred:VerifiableCredential. But .../1872 is not the same as _:b1. The vocabulary will allow the deduction of additional, and unwanted type allocations.

I believe the vocabulary (ie, the ontology) mixes up the container with the contained.

I am not sure what is the best way of handling that. Maybe just remove the range setting, and/or describing the range in English prose, referring to an RDF graph whose single top level resource (ie, a resource that does no appear as an object of any triple) is of type cred:VerifiableCredential. I do not know if there exist some more formal way of expressing that, I would hope @pchampin has a good idea for that.

Note, b.t.w., that the same is probably true for other properties like proof, but I am not sure where the ontological definition of that property is.

cc @dlongley @msporny @OR13

[OR13]

This seems related to the other @container question:

#881

I believe the vocabulary (ie, the ontology) mixes up the container with the contained.

possibly.

I think it would be worth taking the time to explain the high level relations we are hoping for these top level classes to afford, and the role the JSON-LD context syntax plays in communicating them... We should strive to ensure that the context and the normative text stay closely aligned... and in particular that the context is not stricter than the normative test.

[iherman]

I think it would be worth taking the time to explain the high level relations we are hoping for these top level classes to afford, and the role the JSON-LD context syntax plays in communicating them... We should strive to ensure that the context and the normative text stay closely aligned... and in particular that the context is not stricter than the normative test.

I am not talking about the @context file. The context is not the vocabulary definition, it is only a mapping onto the vocabulary. If we take seriously the assumption that some representation of VC rely on Linked Data expressed in RDF, than the vocabulary must be correct.

[iherman]

This seems related to the other @container question:

#881

Wow, that is a long thread, and I did not pay attention to it, my bad. I think you are right. What you call "weird blank node issue with the proof block." is, I believe, exactly the blank node _:b1 in the example above. And the representation is exactly right per the vocabulary because the object of a proof must be a separate RDF graph (@msporny has explained it in the thread, and I guess the RCH work will make it, possibly, even more clear when it comes).

[iherman]

Hm. It seems that old age is definitely creating a problem with me. Thanks to some cool features of the (new version of) GitRaken client, I realized that I have already raised this issue in #770, and it was recently decided to keep it open as well. I even created, back then, a PR (#771) but which was never merged (I presume due to the versioning issues).

So, closing this issue in favor of #770/#771. And I may have to do something about my weakening memory...