Proposed improvement to the official vocabulary

[iherman]

(I will be happy to produce a PR with these changes, but prefer to get some feedbacks first.)

Reading through the text, and comparing it with the current vocabulary, I would want to propose the following improvements to the latter, to make it as close as possible to the spec text:

1. BitstringStatusListEntry is a subclass of cred:CredentialStatus.

   The cred vocabulary defines the credentialStatus property, whose range is cred:CredentialStatus; better make this statement here to clarify things.

2. statusListCredential range is BitStringStatusListCredential.

3. BitStringStatusListCredential is a subclass of cred:VerifiableCredential

4. statusReference range is a URL (i.e., it is an ObjectProperty)

5. statusSize range is xsd:positiveInteger

6. The messaging part was also incorrect imho. The proper structure is:

   1. Introduce a (new) class, say, BitstringStatusMessage
   2. the range of statusMessage is BitstringStatusMessage
   3. the domain of status and message is BitstringStatusMessage

I was also wondering about the range of cs:statusListIndex which currently says it must be an integer encoded in a string based on 10. Why wouldn't a range xsd:nonNegativeInteger work here? Why this specific text in the spec?

I am also wondering whether it is worth adding a diagram for the vocabulary, just like we have for VC and DI. WDYT?

cc @dlongley

(Edited by adding the item no. 6 above)

[iherman]

Actually, I went ahead, and created a diagram, which helped me to have a better overview of the vocabulary. The results are in #159.

[dlongley]

I think all of the above suggested changes are correct. Similarly, I think we could probably use xsd:nonNegativeInteger for cs:statusListIndex to simplify. I also agree that we need a bit more for the messaging piece like you said (and agree with your proposal).

I do want to ensure that there's room for people to innovate and reuse terms like statusListCredential without needing to subclass BitstringStatusListCredential -- this doesn't prevent or discourage that, right?

[iherman]

I think all of the above suggested changes are correct. Similarly, I think we could probably use xsd:nonNegativeInteger for cs:statusListIndex to simplify.

In contrast to all other changes, this would require a change in the spec itself, though. Just saying...

I do want to ensure that there's room for people to innovate and reuse terms like statusListCredential without needing to subclass BitstringStatusListCredential -- this doesn't prevent or discourage that, right?

Hm. Setting the range for statusListCredential means that for any <K> in the following triple

<abcd> cs:statusListCredential <K> .

an inference engine would deduce a

<K> rdf:type cs:BitStringStatusListCredential .

Ie, if you want to create a special category of credentials, it would be automatically yield a subclass of BitStringStatusListCredential. Is that a problem?

[msporny]

PR #159 has been merged. Can we close this now, @iherman? If so, please close.

[dlongley]

@iherman,

Ie, if you want to create a special category of credentials, it would be automatically yield a subclass of BitStringStatusListCredential. Is that a problem?

Unknown at this time -- I'm inclined to just let this go and not borrow trouble from the future.