DigitalAddressFacet subclasses and is-a vs. has-a confusion

[ajnelson-nist]

Oresteia.json, in today's state (e87a8e0eabe54762fec1347ff0e563173f3ccac0), has a design issue with the Clytemnestra iPhone.

The issue is in this excerpt, where the two Facets were modified to have an @id solely for discussion here:

{
    "@id": "kb:clytemnestra-device-uuid",
    "@type": "uco-observable:Device",
    "uco-core:hasFacet": [
        {
            "@id": "kb:facet-1",
            "@type": "uco-observable:WifiAddressFacet",
            "uco-observable:addressValue": "d0:33:11:13:e7:a1"
        },
        {
            "@id": "kb:facet-2",
            "@type": "uco-observable:BluetoothAddressFacet",
            "uco-observable:addressValue": "d0:33:11:13:e7:a2"
        }
    ]
}

This is an instance of Facets 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.

{
    "@id": "kb:clytemnestra-device-uuid",
    "@type": [
        "uco-core:UcoObject",
        "uco-observable:Device"
    ],
    "uco-core:hasFacet": [
        {
            "@id": "kb:facet-1",
            "@type": [
                "uco-observable:DigitalAddressFacet",
                "uco-observable:WifiAddressFacet"
            ],
            "uco-observable:addressValue": "d0:33:11:13:e7:a1"
        },
        {
            "@id": "kb:facet-2",
            "@type": [
                "uco-observable:BluetoothAddressFacet",
                "uco-observable:DigitalAddressFacet"
            ],
            "uco-observable:addressValue": "d0:33:11:13:e7:a2"
        }
    ]
}

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 that kb:facet-1 and kb:-facet-2, having a class in common, would be kb:clytemnestra-device-uuid's one instance of a DigitalAddressFacet. The relevant OWL mechanics (likely something about qualified cardinalities) would trigger a owl:sameAs inference, collapse kb:facet-1 and kb: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 this DigitalAddressFacet would have two addressValues.

If UCO starts encoding how Facets correspond with their similarly-named UcoObject subclasses, this example in Oresteia will be a significant forcing function towards creating and relating separate objects.

[sbarnum]

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.

[ajnelson-nist]

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.

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 Facet subclasses to enforce that data made today using a certain Facet subclass doesn't get invalidated in a future release because a new subclass of that "formerly specific" Facet subclass was implemented. That is, being a "Specific Facet" is apparently a point of backwards compatibility.

Using intermediary Facet subclasses might be convenient for programming, but there is a non-trivial impact on semantics and inferencing.