core:hasFacet needs to be encoded as and test as an inverse-functional property

[ajnelson-nist]

Background

UCO's core:Facet class behaves in manners that do not seem to be explored previously in ontology engineering. Lacking reference implementations in other ontologies, UCO needs to make clear some behaviors.

One behavior is explaining what the relationship between a Facet and UcoObject is. Issue 378 sets to codifying the classes as disjoint. Next, we should review how "Shareable" a Facet instance is.

It is possible a user could be tempted to share a Facet, for the sake of saving on graph weight when the user knows the Facet's recorded property data are highly likely to be repeated. One example of this is the set of measurement-based, non-classifying properties in ContentDataFacet, i.e. the size and hashes, but not the mimeType. If a user is hashing file sets where they know many file contents will be repeated, they might be tempted to define and reuse one Facet individual.

It's possible core:hasFacet's rdfs:comment definition codifies that this is not intended to be permitted, by its use of the word "particular." Nothing that is encoded (i.e. not English) in the ontology prevents this, however.

In OWL, the way to commit to this pattern of only-one-"Owner"-UcoObject is to declare core:hasFacet a owl:InverseFunctionalProperty. A owl:FunctionalProperty (inverse coming in a moment) states that, if :b is a functional property, then a triple :a :b :x has only one value for :x. If there are two triples :a :b :c and :a :b :d, :c and :d are inferred in OWL to be the same thing. An ontology with those triples is consistent, unless there is also a triple :c owl:differentFrom :d. An owl:InverseFunctionalProperty goes in object-to-subject order instead. If :b is an owl:InverseFunctionalProperty, then two triples :y :b :c and :z :b :c cause OWL to infer that :y owl:sameAs :z.

core:hasFacet should become a owl:InverseFunctionalProperty in order to declare expectations on Facet "ownership". SHACL enforcement should also be able to cover cases where OWL inferencing may have been applied and caused identity-sharing.

Requirements

Requirement 1

A core:Facet instance needs to be understood, and enforced, as only being permitted to belong to one core:UcoObject instance.

Requirement 2

Any implemented SHACL enforcement of a core:Facet being associated with only one core:UcoObject instance must be able to understand owl:sameAs designating two nodes "being" the same concept.

Risk / Benefit analysis

Benefits

• Maintaining single-association of Facets prevents issues where a shared Facet being modified via association with one UcoObject induces unforeseen consequences for another UcoObject.
• It may potentially be better understood to users that a Facet is a part of one and only one UcoObject.

Risks

• SHACL testing for dual "ownership" of a Facet may be computationally expensive.

Competencies demonstrated

Competency 1

Take the following graph as an example.

{
  "@context" {
    "kb": "http://example.org/kb/",
    "core": "https://ontology.unifiedcyberontology.org/uco/core/",
    "core:hasFacet": {
      "@type": "@id"
    }
  },
  "@graph": [
    {
      "@id": "kb:facet-1",
      "@type": "core:Facet"
    },
    {
      "@id": "kb:object-1",
      "@type": "core:UcoObject",
      "core:hasFacet": "kb:facet-1"
    },
    {
      "@id": "kb:object-2",
      "@type": "core:UcoObject",
      "core:hasFacet": "kb:facet-1"
    }
  ]
}

This graph, with no other supplementary statements and with no OWL inferencing, is inconsistent with (what the proposer understands to be) UCO's intended design of Facets not being shared.

Competency Question 1.1

What nodes are in violation of the core:hasFacet having only one subject per object?

The following query encodes this test:

SELECT $this
WHERE {
  $this a core:Facet .
  ?nObject1 core:hasFacet $this .
  ?nObject2 core:hasFacet $this .
  FILTER ( ?nObject1 != ?nObject2 )
}

Result 1.1

kb:facet-1

Competency Question 1.2

Suppose this graph is added:

{
  "@context" {
    "kb": "http://example.org/kb/",
    "owl": "http://www.w3.org/2002/07/owl#",
    "owl:sameAs": {
      "@type": "@id"
    }
  },
  "@graph": {
      "@id": "kb:object-1",
      "owl:sameAs": "kb:object-2"
    }
}

Now, what nodes are in violation? Note the test must now be encoded to consider owl:sameAs:

SELECT $this
WHERE {
  $this a core:Facet .
  ?nObject1 core:hasFacet $this .
  ?nObject2 core:hasFacet $this .
  FILTER ( ?nObject1 != ?nObject2 )
  FILTER NOT EXISTS {
    ?nObject1 owl:sameAs ?nObject2 .
  }
}

(Note from the submitter - this query has not been tested.)

Result 1.2

No nodes should be returned.

Solution suggestion

1. Add the following statement to UCO's Core namespace: core:hasFacet a owl:InverseFunctionalProperty .
2. Add a SHACL-SPARQL rule (example here) that encodes the query from CQ 1.2 above. Apply it within a sh:NodeShape, which doesn't necessarily need to be given an IRI, but would have an objects-targeting triple sh:targetObjectsOf core:hasFacet.

Coordination

• Tracking in Jira ticket OC-238

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-05-12
• Requirements to be discussed in OC meeting, 2022-05-17
• Requirements Review vote occurred, passing, on 2022-06-02
• Requirements development phase completed.
• Solutions Approval to be discussed in OC meeting, 2022-08-25
• Solutions Approval vote occurred, passing, on 2022-08-25
• Solutions development phase completed.
• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page

[sbarnum]

core:hasFacet is definitely intended to be an owl:InverseFunctionalProperty.
I support formally codifying this in the ontology.

[ajnelson-nist]

PR #462 contains the implemented solution for this Issue. The SHACL-SPARQL constraint illustrated in the competency questions has also been implemented, using the sketched JSON-LD with some syntax corrections and adjustments.