Skip to content
This repository has been archived by the owner on Sep 6, 2022. It is now read-only.

Domain of rec:substance #15

Closed
ektrah opened this issue Aug 25, 2022 · 3 comments
Closed

Domain of rec:substance #15

ektrah opened this issue Aug 25, 2022 · 3 comments

Comments

@ektrah
Copy link

ektrah commented Aug 25, 2022

rec:substance
a owl:AnnotationProperty ;
rdfs:domain rec:feeds ;
rdfs:domain rec:isFedBy ;
rdfs:label "substance" ;
rdfs:range [

This seems to say that the domain of the rec:substance predicate are instances of the two classes, rec:feeds and rec:isFedBy. Is this interpretation correct? If yes, is it intended that rec:feeds and rec:isFedBy are classes?

@hammar
Copy link
Contributor

hammar commented Aug 26, 2022

Hi,

Nicely noticed! This is a case of unorthodox punning that we do to support emitting property graph constructs when translating SHACL -> DTDL.

The intent is to symbolize that knowledge graph edges using the properties rec:isFedBy or rec:feeds can have the rec:substance property applied to them. So, the rdfs:domain statements above should really be understood to be not the properties themselves, but triples in which they are the predicate.

Given that RDF does not allow for such constructs natively (at least not until RDF* is standardized), for now, one has to find workarounds. This is such a workaround. Suggestions on alternate representations are most welcome.

@ektrah
Copy link
Author

ektrah commented Sep 2, 2022

Thanks for the explanation! It seems the common workarounds look like this:

(source)

Would one of these be option? (e.g., N-ary Relations)

@hammar
Copy link
Contributor

hammar commented Sep 5, 2022

Since REC4 is now merged into the main REC repo we will be archiving this repository, and I'll close this issue. That doesn't imply that this discussion is dead -- would be happy to continue it in that other repo instead.

Unfortunately the proposed solutions would break alignment with Brick Schema, from which the feeds property is borrowed. My suggestion would be that we try and resolve this upstream, by contributions to / work with the Brick colleagues, who, it seems to me, would have ownership over this problem space.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants