are `domain` and `range` correct for all properties in data model?

[TallTed]

handles in brackets indicate the author of that paragraph

Originally posted by @TallTed and @iherman in w3c/vc-data-integrity#175 (comment)

[@TallTed] I noticed the OR circle. I think that's trying to say that "VerifiablePresentation OR VerifiableCredential could be Domain (a/k/a schema:domainIncludes VerifiablePresentation, VerifiableCredential; cannot be rdfs:domain because the two classes are disjoint) of termsOfUse, validFrom, validUntil" — but I don't understand why this would only apply to those three properties. To my mind (and I hope the text and all bear this out), most if not all pictured properties should have schema:domainIncludes VerifiablePresentation, VerifiableCredential. In any case, I would make all these arrows complete arcs, and do away with the OR as well as the vertical connectors now seen between VerifiablePresentation, OR, and VerifiableCredential.

[@TallTed] Note: The current version of the diagram does not have "the OR circle" which was at the point where the vertical line between VerifiablePresentation and VerifiableCredential meet the three arcs to termsOfUse, validFrom, and validUntil.

• [@iherman] For the OR node: the diagram reflects what is in the vocabulary which, on its turn, reflects the spec at least the way I understand it. The 'issuer', 'evidence', etc, properties are only mentioned in conjunction with a credential and not with a presentation. I am not the domain expert here, any change should come from the VCDM spec.

[@TallTed] Ayie! It's doubly good we have these diagrams now, and that they were generated based-on/from the vocabs, which were generated based-on/from the spec — because this shows that the specs and the vocabs are wrong!

[@TallTed] The wrongness I see is that only 3 of the pictured properties have schema:domainIncludes both of the classes (VerifiablePresentation and VerifiableCredential); i.e., that only VerifiablePresentation may have a holder (VerifiableCredential may not), while only VerifiableCredential may have a credentialSchema or confidenceMethod (among others, which VerifiablePresentation may not).

[@iherman] Whether it is wrong or not, I do not know. I am in the humble position of translating the spec into the RDF world, and I do not claim to be a domain expert for VCs and VPs.

[@iherman] @TallTed I would prefer not to discuss this problem in this issue. Would you mind raising a separate issue in the VCDM repo and possibly discuss it there?

[@TallTed] The current version of the diagram in question (which is evolving, so may not now exactly match the description written here) is:

[OR13]

I really like this picture, but I am not sure it reflects working group consensus.

I would like to see it align with working group consensus and capture normative reality, it seems very helpful.

[TallTed]

[@OR13] I really like this picture, but I am not sure it reflects working group consensus.

It would be VERY helpful if you (and others!) could point out the specific departures from consensus you see, as well as any differences between that consensus you see and the spec as it stands, not to mention anywhere the (current) diagram and the spec as it stands.

The goal is definitely for it to "align with working group consensus and capture normative reality"!

[OR13]

@TallTed

From my side the main question I have is on the RDF classes. Specifically reserved rdf classes, domain and range on predicates etc ...

I think some discussion on that will easily resolve the issue.

@msporny seemed unsure on the call regarding this picture, which parts stand out to you as needing more discussion in order to represent consensus of the group as opposed to scaffolding from @iherman (which we are all lucky enough to have a picture to react to, thank you).

[dlongley]

Something that is missing here from both VerifiableCredential and VerifiablePresentation is the relatedResource property.

[OR13]

@dlongley I filed #1265 related to your comment above, so this issue can remain focused on domain and range topic.

[iherman]

@OR13

From my side the main question I have is on the RDF classes. Specifically reserved rdf classes, domain and range on predicates etc ...

I think some discussion on that will easily resolve the issue.

I cannot process this comment, it is too vague. Please, be specific

What I did was:

1. looking at the spec I derived the vocabulary in the way I understood the spec. The spec, mostly, concentrates on properties that are defined on specific concepts.
   • The concepts become classes, which also serve as domains in this translation.
   • The ranges are
     • either specifically designated in the spec (as literals of a given type or concepts represented by classes like a VC)
     • or vaguely referring to an abstract concept where the user is required to use a type statement, which means an abstract supertype is implicitly used.
     • These are then I assigned the formal range. Otherwise, the range remains unspecified
2. I derived the graphic representation from the vocabulary (and the vocabulary only). The picture is only a helping tool for the vocabulary, nothing more!

No doubt I may have made mistakes in these steps. The only way I can proceed is if you specifically point at a mistake in creating the vocabulary (or where the diagram differs from the vocabulary), possibly as a separate issue.

[iherman]

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

• no resolutions were taken

View the transcript

2.1. are domain and range correct for all properties in data model? (issue vc-data-model#1263)

See github issue vc-data-model#1263.

Kristina Yasuda: @dmitri: here is the issue: w3c/vc-jose-cose#140.

Kristina Yasuda: on the controller doc I mean.

Ted Thibodeau Jr.: <refering to properties> most properties apply to VCs and not VPs - one property supports both, one is VP-specific. Concerns this is incorrect.

Manu Sporny: some difficulties in evaluating the diagram - the properties can exist on the VP and VC simulataneously.

Ted Thibodeau Jr.: credentialSchema vs presentationSchema, the conversation settled on a VP being a VC with some specialness to it.

Manu Sporny: the VP has different properties, can hold a bundle of verifiable credentials.

Ted Thibodeau Jr.: can you not put VCs in VCs?

Manu Sporny: you can put them in spots but not in the way that you can do so with a VP.

Ted Thibodeau Jr.: people want to associate a verifiable credential with a holder, this diagram makes that impossible.

Manu Sporny: I think this comes down to suggested use - since it is an open world model, they can add whatever properties they want.

[iherman]

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

• no resolutions were taken

View the transcript

3.1. are domain and range correct for all properties in data model? (issue vc-data-model#1263)

See github issue vc-data-model#1263.

Brent Zundel: only one issue so far.
… looking for before-cr or post-cr comments.

Manu Sporny: discussed this yesterday. Ted mentioned he would think about it.

Brent Zundel: ok, that's ok with me. Ted did you want to share anything now?

Ted Thibodeau Jr.: not yet. This is probably post-cr.

Orie Steele: there are reserved terms that also point to reserved RDF classes.
… we currently have confidenceMethod as a reserved RDF class.
… which maybe implies some future inheritance. but what is the relationship between the reserved predicate and the reserved RDF class.
… what's the thought process around confidenceMethod being reserved in this way, instead of having confidencemethod refer to verification method.
… are these normative.

Manu Sporny: ivan did a lot of this work. we'd need to ask him.

Orie Steele: Does this work reflect working group consensus?

Orie Steele: Is the vocabulary normative?

[iherman]

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

• no resolutions were taken

View the transcript

3. Issue Triage.

See github issue vc-data-model#1263.

Brent Zundel: sounds like Orie is happy to drop it from the main context if we can get it in other contexts.
… now moving to issue triage.

[iherman]

From the minutes:

Manu Sporny: some difficulties in evaluating the diagram - the properties can exist on the VP and VC simulataneously.

Forget about the diagram, that reflects the vocabulary. Actually, forget the vocabulary, that reflects (in my view) the specification...

Let us take a specific example: issuer. The property is defined in § 4.7 and it says:

This specification defines a property for expressing the issuer of a verifiable credential.

It is also part of the terminology section and it says

A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder.

So far so good; the way I interpreted this in RDF land is that the domain of that property includes the VerfiableCredential class. I think that is o.k. with everyone.

The issue we are discussing is why the vocabulary does not also include the VerifiablePresentation class in the domain of issuer. Well, because there is nothing in the spec that would allow me to make that extra statement. There is indeed no reference to a verifiable presentation in relation to the issuer property. Only a few properties are listed in § 4.11 with regard to verifiable presentation, and issuer is not one of those.

I hit the same issue with all the other terms that are discussed here. Did I miss such references?

If we want "the properties can exist on the VP and VC simultaneously" to happen, the specification should

1. Explicitly list in § 4.11 which properties, defined for credentials, can also be used in relation with a presentation; or
2. Make a blanket statement that all properties that are defined for a credential can also be applied to a presentation (and, if there are exceptions, just list them); or
3. Make a blanket statement that no properties in the spec are bounded by a domain statement, ie, they can be applied to any RDF Class under the Sun.

I would not like to see alternative (3) above; our vocabulary is not meant to be that general. Whether alternatives (1) or (2) are chosen is an editorial choice. But I would be against "just" adding the domain statements to the VerifiablePresentation class in the vocabulary, without that being explicitly allowed by the specification; we indeed agreed that the vocabulary document does not define anything by itself, it should just reflect what the VCDM (or, respectively, the DI) document specifies.

(Obviously, I am happy to make the changes in the vocabulary and, eventually, adapt the diagram once all this is clarified.)