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

[ajnelson-nist]

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

• Design is aligned for current "Data structure" classes.
  • The one exception is core:Compilation and its subclass hierarchy. core:Compilation is analogous to co:Set but has been around since UCO's beginning as a general, unordered object-aggregation.
• Design is clarified for future users of types:Thread and other structures that will potentially be imported from the Collections Ontology.

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

• For UCO 2.0.0: Change types:Thread rdfs:subClassOf core:UcoThing to types:Thread rdfs:subClassOf core:UcoInherentCharacterizationThing.
• For UCO 1.x.0: Because a superclass change may not be a tenable thing to "Deprecate" in the ontology with SHACL, add a test to uco-qc.ttl that fails CI on detecting a class definition that is a subclass of both uco-core:UcoObject and co:Collection. (co:Collection is the CO topmost class, just under owl:Thing.)

Coordination

• Tracking in Jira ticket OC-285
• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-11-29
• Requirements to be discussed in OC meeting, 2022-12-08
• Requirements Review vote occurred, passing, on 2022-12-08
• Requirements development phase completed.
• Solution announced to OCs on 2023-01-18
• Solutions Approval to be discussed in OC meeting, 2023-01-26
• Solutions Approval vote occurred, passing, on 2023-01-26
• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next release
• develop state with backwards-compatible implementation merged into develop-2.0.0
• Backwards-incompatible implementation merged into develop-2.0.0
• Milestone linked
• Documentation logged in pending release pages

[plbt5]

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]

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]

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]

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.