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.)

[iherman]

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

• no resolutions were taken

View the transcript

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

See github issue vc-data-model#1263.

Orie Steele: The vocab does not perfectly reflect the spec for abstract classes and domain and ranges... thats part of the challenge.

Ivan Herman: I would argue this issue (1263) should be pre-CR.
… diagram and vocabulary should reflect what's in the normative spec text; nowhere in the spec does it specify that these can be used in VPs.
… if there is a desire to include these in the vocabulary or the diagram, we can do that, but only if the relevant spec text changes pre-CR.

Ted Thibodeau Jr.: I understand the normative text is upstream of the diagram, but the diagram is consequential and without it I would not have noticed this VC/VP delta.

Sebastian Crane: +1 TallTed (IRC) to importance of diagram to be correct and available.

Orie Steele: +1 TallTed.

Ted Thibodeau Jr.: I think these discrepancies deserve attention.

Orie Steele: There is another example where vocab, diagram and text seem misaligned: abstract classes.
… abstract class for CredentialSchema types are, for example, very important in the work items around JSONSchema.
… so I support clarifying this and making it more explicit pre-CR.

Ivan Herman: I volunteer to be assigned this issue.
… and as a sidenote, I want to briefly summarize what Orie means by abstract classes.
… abstract classes allow properties to be inherited by subtypes, this is a powerful tool.
… (scribe struggles to summarize).

Orie Steele: if you don't like RDF just think of the abstract classes and Interfaces in TypeScript : ).

Orie Steele: FWIW, I think the classes should be in the spec, or removed from the vocab, since its confusing if they only appear in vocab.

Dave Longley: +1 yes, the VCDM just uses a simple object / class-based modeling constraint to express information as opposed to "anything goes".

Dave Longley: which happens to map cleanly to RDF statements of subject -> property -> value.

Manu Sporny: We should have a section in the specification that defines the abstract classes for those that care about RDF, that'll close that loop, I'm not hearing any objections to that path.

[bumblefudge]

heyo i can provide an extra review to check for dotted ts and crossed is (soft self-assign)

[bumblefudge]

was there a link for an updated diagram?

[iherman]

was there a link for an updated diagram?

Actually... the link is the most up-to-date available. The question is the fate of relatedResource, which is not on the diagram yet, see #1263 (comment), but also #1265.

[iherman]

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

• no resolutions were taken

View the transcript

2.3. 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: domain & range question.
� In addition to the JWk properties and the context, there are a lot of properties that have a domain and range expressed. some might not be correct.

Ivan Herman: let's put the RDF issues aside.
� just looking at the current document, there are a number of properties, such as issuer, that are described in the spec only in VCs.
� There is no line between what is only in VCs or VPs and what are usable in both.
� This manifested when I translated the spec into the vocab and created a diagram. it became very visible.
� What I need as a vocab expert is for each of them a clear statement in the specification, somewhere, that says it is usable in a VP as well as VC or not.
� The rest would be me doing editorial work.

Dmitri Zagidulin: it would be incredibly useful to also allow termsOfUse in a VP, in addition to VC.

Ivan Herman: The range is similar, but there aren't many specified in the spec.
� I'd propose that someone looks at all the properties defined and does a triage to identify what needs more work.

Brent Zundel: would folks be opposed to, in general, saying any property in the data model could be used in either VCs or VPs.

Dmitri Zagidulin: +1 to that :).

Ivan Herman: I would. we have some like credentialSubject should not be in the presentation.

Manu Sporny: Correct, we definitely don't want to do that.

Ted Thibodeau Jr.: for those, it seems we need parallel presentationSubject, etc.

Brent Zundel: so the answer is no. ;).
� so we need a volunteer to do the triage, AND we'll need it added to the spec.

Ted Thibodeau Jr.: concern: credentialSubject suggests maybe there's a parallel for PresentationSubject.

Manu Sporny: this sounds like... the scope of this is rapidly expanding and we're going into CR. so big -1.
� too hard to consider this late in the game.
� for example, presentationStatus wouldn't make same. Issuer for VPs, etc.
� the idea that VCs and VPs are the same thing is a bad path to go down.
� Yes, we need to look at the domain range.

Brent Zundel: then lets limit this to makes sure the ... this issue is seeking reconciliation between the vocabulary and the specification.

Ivan Herman: at the moment, there is no reconciliation needed. They are in sync. TODAY.
� the question is whether or not thats ok.

Ted Thibodeau Jr.: my concern is that what's in the spec may not be correct/as intended. I trust that Ivan has accurately reflected in the spec, in the vocab and diagram.
� that revealed my concerns. With simpathy for the can of worms, that's when things come up.
� some properties make sense on both VCs and VPs.
� Some don't. We should state that clearly.
� just because their named in a particular way isn't enough.

Brent Zundel: so the scope of this issue is, this is what the scope says looking at the vocab. we need to make sure it is what we meant. Not an increase in scope.

Ted Thibodeau Jr.: +1 to brentz's understanding and restatement.

Ivan Herman: +1 to what Brent said.

Joe Andrieu: The can of worms to avoid is not what we just talked about, we have to do the work that you clarified Brent... trying to harmonize VCs and VPs is problematic, they are different things... we shouldn't even assume that any properties are common.

Manu Sporny: that sounds right. +1 that we need to make sure the vocabulary expresses what we meant to express.
� if implementers are telling us we need property x or y, that's one thing. but if we start doing that to add new properties to one or the other.

Brent Zundel: the action now: we need a number of volunteers to go through the spec and compare it to the diagram and see if it says what we meant it to say.
� I'm willing to assign myself and work on it on Saturday.

Juan Caballero: i can do it with you this weekend, brent.

Manu Sporny: I'm happy to be added to that list. I've gone through, I do think it says what the spec meant.

Brent Zundel: for those who have signed up to review. let's get those in no less than a week from today so Ivan can act on that feedback.

Ivan Herman: I will be out from next Sunday.

Brent Zundel: so less than a week, so Ivan has a chance to review before next week.

[brentzundel]

@iherman questions I had while reviewing the vocabulary, the spec, and the diagram

1. though I recall conversations that validFrom and validUntil would apply to the verifiablePresentation as well as the verifiableCredential, I am not seeing any support in the spec for this. I consider this a bug in the spec.
2. what is the relationship between the vocabulary at https://www.w3.org/2018/credentials/ and the jsonld file at vocab/credentials/credentials.jsonld? credentials.jsonld seems very out of date.
   I don't consider my opinion to be blocking for any path forward the VCWG finds consensus on.

[iherman]

@iherman questions I had while reviewing the vocabulary, the spec, and the diagram

1. though I recall conversations that validFrom and validUntil would apply to the verifiablePresentation as well as the verifiableCredential, I am not seeing any support in the spec for this. I consider this a bug in the spec.

You are right. This should be part of the review of the spec (cc @msporny)

2. what is the relationship between the vocabulary at https://www.w3.org/2018/credentials/ and the jsonld file at vocab/credentials/credentials.jsonld? credentials.jsonld seems very out of date.

That is a leftover; again I have to refer to @msporny. The correct, new entries are in the v2 subdirectory of the repo. More exactly, the jsonld file is generated into github.io into that subdirectory.

I don't consider my opinion to be blocking for any path forward the VCWG finds consensus on.

[iherman]

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

• no resolutions were taken

View the transcript

2.3. 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: We might need Ivan for this issue.
… Last time we discussed this, Brent said the action was to have volunteers to go through the spec and compare to the diagram and see if it says what we meant it to say. Is there any progress on this?

Manu Sporny: Yeah, kinda sorta progress, what is going to have to happen is people will have to make sure all of this is correct. What we probably need specifically ... well, there are a couple of problems when this was first raised was that there were no base / super classes.
… Those exist in a PR now and I forget if its getting merged soon or not. The VerifiableCredentialGraph exists now and it was missing. The question is: does everything exist in the diagram now?
… People will need to make sure everything in the diagram exists in the spec. This doesn't feel like a "ready for PR" thing, it looks like a "people need to double check", we need volunteers to assign to this. I will also note that myself, Brent, Juan, etc. are assigned.
… It just needs to be reviewed by us.

Kristina Yasuda: Ok.
… Did you say that those PRs merged right before this call -- partially address this?

Manu Sporny: Yes, there is another... looking.

Manu Sporny: https://w3c.github.io/vc-data-model/#vocabularies.

Manu Sporny: Base classes now exist in the vocabulary section -- that was a huge part of the work that needed to be done and that's now merged.
… I think the assertion at this point is that we have fixed everything and we just need review.

Kristina Yasuda: Ok.
… Do we have a good label for that?

Manu Sporny: No, we don't have one for "needs review".

Kristina Yasuda: Ok will do "close after reviews" or something.

[iherman]

The issue was discussed in a meeting on 2023-10-18

• no resolutions were taken

View the transcript

2.2. 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: What's the status of this?

Ivan Herman: This turned messy since end of August, including new versions of vocabulary/diagrams, which have been merged.
… My proposal would be to close this issue because it's become unmanageable. Someone should take up responsibility of looking at spec and vocab and answer the original question, is domain/range correct yes/no, or if there are changes needed?

Brent Zundel: not sure I agree w/ proposal to close issue.

Ivan Herman: There are some issues there / discussion, that have been put into changes.
… That's difficult to follow. Diagrams have been updated, vocabularies have been updated.

Brent Zundel: We would open a new issue to make sure domain/range matches what's in the data model?
… TallTed, this is your issue, would you be opposed to that course of action?

Orie Steele: Is there a link to the diagram that landed? I feel the diagram in the issue is helpful.

Ted Thibodeau Jr.: I would not be opposed to a new issue that doesn't have the history, don't know how beneficial? Opposed to closing. We need a tracking issue.

Orie Steele: +1 TallTed.

Brent Zundel: Agree, this is something that needs to be completed.

Ivan Herman: What I proposed is what Ted proposed.

Phillip Long: +1 to open this issue fresh.

Ivan Herman: Create a new issue to check domain/range.

Brent Zundel: Ivan, can you open the new issue?

Ivan Herman: Yes. And I will then close this one.

[iherman]

As agreed on the call (see #1263 (comment)), a fresh issue has been raised at #1319; closing this issue.