-
Notifications
You must be signed in to change notification settings - Fork 16
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
DigitalAddressFacet subclasses and is-a vs. has-a confusion #97
Comments
The requirement that an object should only ever have one instance of any particular Facet class is applicable to any specific Facet class and is not applicable to its superclasses or subclasses. If we tried to apply it to superclasses then ALL instances would fail as ALL Facet subclasses are all subclasses of Facet. |
I appreciate how we would like that to be true. We should be aware that in RDFS inferencing, such a requirement will take care to encode. For instance, one consequence is we may need to "freeze the leaf set" of Using intermediary |
Oresteia.json, in today's state (
e87a8e0eabe54762fec1347ff0e563173f3ccac0
), has a design issue with the Clytemnestra iPhone.The issue is in this excerpt, where the two
Facet
s were modified to have an@id
solely for discussion here:This is an instance of
Facet
s confusing is-a vs. has-a object relationships. It is also an instance of a potential conflict when RDFS subclassing is used.UCO Issue 445 details the issue with subclassing and a yet-unencoded design point. The issue is: If RDFS expansion (/inferencing) were applied, several more subclasses would be added into this snippet. I'll add just a few - there are significantly more that would be added, but what comes in is sufficient for demonstration.
Informal discussion in committee meetings has led me to understand that an object should only ever have one instance of any particular
Facet
class. If that were encoded in OWL, that would mean thatkb:facet-1
andkb:-facet-2
, having a class in common, would bekb:clytemnestra-device-uuid
's one instance of aDigitalAddressFacet
. The relevant OWL mechanics (likely something about qualified cardinalities) would trigger aowl:sameAs
inference, collapsekb:facet-1
andkb:facet-2
into one object with two IDs (or just duplicate all properties from either to the other), and then trigger a SHACL validation error because thisDigitalAddressFacet
would have twoaddressValue
s.If UCO starts encoding how
Facet
s correspond with their similarly-namedUcoObject
subclasses, this example in Oresteia will be a significant forcing function towards creating and relating separate objects.The text was updated successfully, but these errors were encountered: