search

ucoProject / UCO

This repository is for development of the Unified Cyber Ontology.
Apache License 2.0
78 stars 34 forks source link

UCO should hint at Facet associations #634

Open ajnelson-nist opened 3 hours ago

ajnelson-nist commented 3 hours ago

Background

At present, any instance of a Facet is freely associable with any instance of a UcoObject. This is in support of duck typing, where being a Foo implies having behaviors like a Foo, but having behaviors like a Foo does not necessarily imply being a Foo. However, at present, UCO has no encoding of this. "Foo" has no association with "FooFacet" stronger than any other "BarFacet" - e.g., uco-observable:File and uco-observable:FileFacet are as strongly related by structural design as uco-observable:File and uco-observable:URLFacet. The string pattern-matching is clear, but would not cover cases where Facets should be associated with non-matching name patterns, like uco-identity:Person and uco-identity:SimpleNameFacet.

There is a mechanism to express this in OWL. For File and FileFacet, this block of Turtle states that "If a thing is a File, there exists one FileFacet linked with hasFacet."

uco-observable:File
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty uco-core:hasFacet ;
        owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
        owl:onClass uco-observable:FileFacet ;
    ] ;
    .

(Syntax can be reviewed by checking for ObjectExactCardinality in OWL 2 Web Ontology Language Mapping to RDF Graphs.)

Adding this encoding does not cause data where there's a File with no FileFacet to be declared invalid. OWL's open-world assumption leaves it fine to not record a FileFacet.

SHACL is not an appropriate mechanism to make such an expression. This statement of existence can be represented with sh:qualifiedValueShape, but there's nothing being constrained, except the uniqueness of the specific facet type (i.e, no File can have two different FileFacets). Specific facet type uniqueness is left out of scope of this proposal, and requires resolution of Issue 595. The present proposal intends only to hint an inheritable association.

Requirements

Requirement 1

UCO SHOULD hint the Facet classes associated with any UcoObject subclass.

Requirement 2

The hinting mechanism MUST support arbitrary Facet associability---that is, if a pattern association is not present (like a "Foo" and "FooFacet" being related by suffixing), hard-coding an association should be possible.

Requirement 3

The hinting mechanism MUST NOT impede other abilities to associate Facet instances with UcoObject instances.

Risk / Benefit analysis

Benefits

This proposal helps to remove some of the obfuscation caused by housing properties in Facets rather than directly on UcoObjects. Before this proposal, the tie between a File and the fileName property are as strong as the tie between a File and a latitude value.

Adoption of this proposal enables focused discovery of properties entailed by Facets from parent classes. For instance, the CASE JSON-LD Stubs repository shows a stub for uco-observable:ArchiveFile here. The Facet hinting in this proposal enables linking in the directly associated ArchiveFileFacet, as well as the parent class's FileFacet. Both associations were drawn from the "Foo"/"FooFacet" pattern-match, which will be part of the implementation this proposal begins.

Reviewing the Facet hints also provides an opportunity to review Facets that have no current associated UcoObject subclass, clearing up currently unclear and/or forgotten use cases.

Risks

This proposal brings more OWL structural syntax into UCO. This risk and syntactic complexity increase is suggested as acceptable because the need is believed inappropriate to meet with SHACL.

Concerns with accidental inference capabilities have been noted by some UCO Ontology Committee members. The restriction illustrated in the proposal background has the following inferential effects:

Last, while the "Foo"/"FooFacet" pattern will generate many of the owl:Restrictions, several Facet classes don't match this pattern, and will require manual attention and association. A comment following this proposal will list the known non-mechanically-associable Facets subclasses.

Competencies demonstrated

The key competency generated in this proposal is support for mechanical discovery of properties of UcoObjects ("domain objects") that have been obscured by separation into Facets. The JSON-LD stubs repository, especially with its ArchiveFile demonstration, is left as the demonstration of this new competency.

Solution suggestion

Coordination