search

ucoProject / UCO

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

types:Thread is one level too high in the subclass hierarchy #509

Closed ajnelson-nist closed 1 year ago

ajnelson-nist commented 1 year ago

Background

Issue 470 posed a question about what the superclass of types:Thread should be within the UCO namespaces. At the time that question was written, core:UcoThing was being introduced, and was considered the correct answer.

core:UcoThing was being introduced in Issue 430. Between the beginning and ending of that issue, another intermediary class was introduced for a class hierarchy of those UcoThings that are not UcoObjects or UcoFacets: UcoInherentCharacterizationThing.

The types:Dictionary class became a subclass of core:UcoInherentCharacterizationThing, as part of resolving 430. However, types:Thread, as a "Data structure" ontology class that we have chosen to not introduce into the UcoObject subclass hierarchy (particularly in discussion on Issue 393 that introduced types:Thread), is not a subclass of core:UcoInherentCharacterizationThing. This appears to have been an implementation oversight during the resolution of 430.

Requirements

Requirement 1

OWL classes in UCO being used as "Data structure" classes should exist in the same subclass hierarchy below core:UcoInherentCharacterizationThing.

Requirement 2

types:Thread must be moved in the subclass hierarchy to alongside other "Data structure" classes.

Risk / Benefit analysis

Benefits

Risks

Moving types:Thread to be a subclass of core:UcoInherentCharacterizationThing will mean it will no longer be permitted to define a node as, say:

kb:some-thing
  a types:Thread, observable:ObservableObject ;
  .

This would be a member of two disjoint classes (UcoObject and UcoInherentCharacterizationThing), and thus would be invalid.

Nor would it be permitted to define a new class:

kb:SomeThreadClass
  rdfs:subClassOf types:Thread, observable:ObservableObject ;
  .

(UCO test mechanisms don't currently review this in an automated manner.)

While this appears to capture the design intent of Issue 430, due to 1.0.0 defining types:Thread as a subclass of the most-general UcoThing, implementing this fix would be a backwards-incompatible change that would have to wait for UCO 2.0.0.

Competencies demonstrated

Competency 1

A user is interested in a yet-unexplored usage pattern for co:List based on some ObservableObject---let's say representing traceroute results---and wonders how to define a new class.

Competency Question 1.1

Before the change in this proposal, what looks like an appropriate subclassing, according to types:Thread?

Result 1.1

ex:IPAddressRoute
    a owl:Class , sh:NodeShape ;
    rdfs:subClassOf observable:ObservableObject, co:List ;
    sh:property [
        sh:class observable:IPv4Address ;
        sh:path ( co:item co:itemContent ) ;
    ] ;
    .

(This also breaks from the current UCO design pattern with Facets, which is another of the reasons we chose to move co:* subclasses over to UcoInherentCharacterizationThing.)

Competency Question 1.2

With this fix, what is the appropriate design style?

Result 1.2

ex:IPAddressRouteFacet
    a owl:Class , sh:NodeShape ;
    rdfs:subClassOf core:Facet ;
    sh:property 
      [
        sh:class co:Thread ;
        sh:path ex:hasIPv4AddressRoute ;
      ] ,
      [
        rdfs:seeAlso observable:MessageThreadFacet ;
        sh:class observable:IPv4Address ;
        sh:path ( ex:hasIPv4AddressRoute co:item co:itemContent ) ;
      ]
      ;
    .

Solution suggestion

Coordination

plbt5 commented 1 year ago

I'd suggest to defer resolution of this CP until clarification has been achieved about the meaning and use of the core:Facet by the FDP-WG, because this could change the meaning and position of UcoInherentCharacterizationThing

ajnelson-nist commented 1 year ago

I'd suggest to defer resolution of this CP until clarification has been achieved about the meaning and use of the core:Facet by the FDP-WG, because this could change the meaning and position of UcoInherentCharacterizationThing

I don't think that will be necessary.

The current definition of disjoint classes in UCO's core namespace is here:

[]
    a owl:AllDisjointClasses ;
    owl:members (
        core:UcoInherentCharacterizationThing
        core:UcoObject
    ) ;
    .

Facets are thus mostly out of scope of the discussion for this Issue. The places where I used Facet in my illustrations in this ticket pertained to existing design patterns. Further, the Facet Design Pattern Working-Group (FDP-WG) is highly likely to be proposing backwards-incompatible changes that would need to wait until UCO 2.0.0.

I think it would be helpful for us to approach whatever the working-group's 2.0.0 resolution is with only one design pattern, rather than the current pattern and patterns implemented without regard for Issue 509.

sbarnum commented 1 year ago

I would concur that this CP is likely not encumbered by any questions with facets.

And to clarify, Alex is correct above that core:UcoInherentCharacterizationThing and core:UcoObject are disjoint but it should also be noted (since the topic of facets weas raised in relation to this discussion) that core:Facet is a subclass of core:UcoInherentCharacterizationThing. All facets are "a grouping of characteristics unique to a particular inherent aspect of a UCO domain object". So, because of the assertion that core:UcoInherentCharacterizationThing and core:UcoObject are disjoint, it also follows that core:Facet and core:UcoObject are disjoint.

ajnelson-nist commented 1 year ago

One interesting issue arose in testing. I implemented the class of Competency Question 1.1 as an XFAIL test, and encountered that the Collections Ontology in some cases (including co:List) uses a subclassing pattern that would not show in RDFS inferencing that a class is (eventually) a subclass of co:Collection. I excerpted the particular pattern for the test after converting CO's RDF-XML format to Turtle:

co:List
    a owl:Class ;
    rdfs:comment "This definition is excerpted from co:."@en ;
    rdfs:subClassOf [
        a owl:Class ;
        owl:intersectionOf (
            co:Bag
            [
                a owl:Restriction ;
                owl:onProperty co:item ;
                owl:allValuesFrom co:ListItem ;
            ]
        ) ;
    ] ;
    .

RDFS inferencing would look for co:List rdfs:subClassOf co:Bag. The above pattern would not work in RDFS inferencing, and instead OWL inferencing would be required to infer the class hierarchy.

This is the explanation for why the SHACL-SPARQL query looks more complex for the Collections Ontology side vs. UCO's side:

PREFIX co: <http://purl.org/co/>
PREFIX core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT $this
WHERE {
    $this
        rdfs:subClassOf*/(owl:intersectionOf/rdf:rest*/rdf:first)?/rdfs:subClassOf* co:Collection ;
        rdfs:subClassOf* core:UcoObject ;
        .
}

This pattern is tested in PR 516 here.