Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

expires rdfs:domain intersection vs expires schema:domainIncludes union #188

Closed
TallTed opened this issue Sep 5, 2023 · 4 comments
Closed
Assignees
Labels
CR1 This item was processed during the first Candidate Recommendation phase.

Comments

@TallTed
Copy link
Member

TallTed commented Sep 5, 2023

Originally posted by @TallTed in #184 (comment)

According to @iherman in w3c/vc-data-model#1262 (comment)

the domain expired is set to both (i.e., the union) of Proof and VerificationMethod.

Note that expires rdfs:domain Proof, VerificationMethod does not set rdfs:domain to the union of Proof and VerificationMethod, but rather to their intersection; that is, any entity with the property expires must be both a Proof and a VerificationMethod.

For the apparently intended union, where an entity with the property expires could be either a Proof or a VerificationMethod, rdfs:domain must be changed to schema:domainIncludes.

Suggested change
domain:
- sec:Proof
- sec:VerificationMethod
domainIncludes:
- sec:Proof
- sec:VerificationMethod

Comment by @msporny msporny 3 days ago

@iherman would have to add this to the yml2vocab tool, as I don't think it has a domainIncludes property? Thoughts, @iherman?

@iherman
Copy link
Member

iherman commented Sep 5, 2023

Where have you seen this, @TallTed ? The intention of the tool is definitely to set the multiple domains to a union; see, for example:

cred:termsOfUse a rdfs:Property ;
    rdfs:domain [ owl:unionOf (cred:VerifiableCredential cred:VerifiablePresentation) ] ;
    rdfs:range cred:TermsOfUse ;
    rdfs:label "Terms of use" ;
    rdfs:isDefinedBy <https://www.w3.org/TR/vc-data-model-2.0/#defn-termsOfUse>, <https://w3.org/2018/credentials#> ;
    vs:term_status "reserved" ;
.

in https://w3c.github.io/vc-data-model/vocab/credentials/v2/vocabulary.ttl. Multiple ranges in the yml file yield intersections, but that is a different matter.

@TallTed
Copy link
Member Author

TallTed commented Sep 5, 2023

rdfs:domain [ owl:unionOf (cred:VerifiableCredential cred:VerifiablePresentation) ]

OK, the above does what you described (union) via the blank node object of the rdfs:domain predicate.

This end result is not obvious when looking at the YAML domain statements.

Elsewhere, you expressed some reluctance to "introduce OWL ontology statements on the vocabulary" ... but that's necessary for the above, as expressed.

So are we, or are aren't we, relying on OWL ontology statements?

@msporny msporny added the CR1 This item was processed during the first Candidate Recommendation phase. label Sep 9, 2023
@iherman
Copy link
Member

iherman commented Sep 9, 2023

rdfs:domain [ owl:unionOf (cred:VerifiableCredential cred:VerifiablePresentation) ]

OK, the above does what you described (union) via the blank node object of the rdfs:domain predicate.

This end result is not obvious when looking at the YAML domain statements.

True, and I should have probably documented it in the Readme of yml2vocab. It somehow made sense that several domain references mean a union, several range references mean an intersection...

I have added a paragraph to the Readme.

Elsewhere, you expressed some reluctance to "introduce OWL ontology statements on the vocabulary" ... but that's necessary for the above, as expressed.

So are we, or are aren't we, relying on OWL ontology statements?

Touché :-) There are cases, like this one, where we really need a way to express things and RDFS is simply too poor. Actually, if you look at the TTL file, for example, there is also use of owl's object and datatype properties, deprecated properties... things that are useful to document and RDFS is simply unable to do.

I think my comment above refers to a complexity level. If an OWL statement can be 'handled' by some rule level reasoning (say, OWL-RL) then it can be expected that many triple stores, sparql engines, etc, can handle the statement if they do any kind of reasoning in the first place. If we get to statements that rely on more complex OWL-DL, let alone OWL-Full reasoning, then we should keep away from those.

That being said: can we close this issue, @TallTed ? I do not think there is any real action to be taken here...

@TallTed
Copy link
Member Author

TallTed commented Sep 11, 2023

That being said: can we close this issue, @TallTed ? I do not think there is any real action to be taken here...

Yes, I think my questions have been answered satisfactorily. Anything else I spot can be fresh issues/PRs.

@TallTed TallTed closed this as completed Sep 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CR1 This item was processed during the first Candidate Recommendation phase.
Projects
None yet
Development

No branches or pull requests

3 participants