UCO ontology files should make room for resources about other ontologies

[ajnelson-nist]

Disclaimer

Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.

Background

This proposal is, in short, "Code-motion."

The UCO IRI structure was revised recently to follow this form, originally prescribed and implemented in CASE 0.4.0, Change Proposal 34:

'https://ontology.unifiedcyberontology.org/' resource '/' sub-resource '/' concept

To better understand by example, consider the action:Action concept, which has this IRI:

https://ontology.unifiedcyberontology.org/uco/action/Action

Some question had come up during this proposal about the redundant-seeming inclusion of the resource path-element. Wouldn't that always be uco for UCO, and case for CASE?

The resource path-element was left to leave room for expansion, so UCO would be able to deploy ontology files that might not necessarily be entirely under UCO's conceptual umbrella.

UCO's transition to SHACL has presented a motivation to make use of this flexibility. Often, ontologies are implemented in OWL, and concepts might be found worth integrating into UCO. However, it is so far infrequent that other ontologies being reviewed by UCO provide SHACL shapes for validating data that use concepts from those ontologies.

To maintain a separation of ontology files fully scoped to UCO from ontology files that are developed to improve integration with other ontologies, this proposal will move UCO's Turtle files down a directory.

Requirements

Requirement 1

UCO must be able to support delivery of ontology resources that could arguably be independent of UCO conceptually. In particular, SHACL shapes for an imported, non-SHACL ontology must be integrable with UCO ontology data for the sake of SHACL validation.

Requirement 2

Resources that are developed in the separable scope of one ontology should be maintained in a location that makes clear the scope. Further, such a location should be visibly consistent within UCO's file storage structure and its IRI scheme.

Risk / Benefit analysis

Benefits

• UCO's directory layout will assist in presenting cross-ontology integration.
• With SHACL shapes developed in independently-namespaced files, there is the potential for UCO to serve as an incubator of SHACL practices, field-testing shapes and possibly performing technology transfer back upstream.

Risks

• File motion may confuse consumers of UCO's ontology repository, as hard-coded path references to files could become invalid. This is believed to be straightforward to discover and rectify, and hence believed to be low-risk.

Competencies demonstrated

Competency 1

A proposal (coming in a few moments) will bring forward integration of the Collections Ontology (CO) with UCO classes pertaining to ordered lists. CO is implemented as an OWL2 DL ontology, and predates SHACL. To validate CO data, UCO would need to develop SHACL shapes scoped to CO concepts.

(Several future proposals are considering incorporating the Semantic Sensor Network ontology, which also does not yet implement SHACL. So, CO will not be the only need to make organizational space available.)

Competency Question 1.1

Under what directory would UCO's development of CO concept review occur?

Result 1.1

Reviewing the directory structure, ontology/* shows Turtle definition files per ontology. ontology/uco would house the current UCO Turtle files. ontology/co would house new Turtle files for the Collections Ontology.

Competency Question 1.2

From what IRI base would CO resources be provided?

Result 1.2

The IRI base of CO SHACL shapes would be https://ontology.unifiedcyberontology.org/co. This permits delivery of UCO shapes that review usage of CO concepts. E.g., a shape that checks conformance of the co:size property, a owl:DatatypeProperty with range xsd:nonNegativeInteger, could be this:

@prefix co: <http://purl.org/co/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix uco-co: <https://ontology.unifiedcyberontology.org/co/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

uco-co:size-subjects-shape
	a sh:PropertyShape ;
	sh:datatype xsd:nonNegativeInteger ;
	sh:nodeKind sh:Literal ;
	sh:path co:size ;
	sh:targetSubjectsOf co:size ;
	.

That standalone shape would be retrievable from the IRI https://ontology.unifiedcyberontology.org/co/size-subjects-shape. While the shape pertains to the concept defined in the Collections Ontology namespace, UCO handles delivery of the SHACL validation shape.

(Please limit review of this shape in this proposal to the delivery IRIs.)

Solution suggestion

• Change the paths of all files /ontology/ to be under /ontology/uco/. E.g. /ontology/action/action.ttl would become /ontology/uco/action/action.ttl.
• Update unit test references to ontology files as needed.

Coordination

• Tracking in Jira ticket OC-243

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-05-26
• Requirements to be discussed in OC meeting, 2022-06-02

• Requirements Review vote occurred, passing, on 2022-06-13
• Requirements development phase completed.
• Solution announced to OCs on 2022-06-22
• Solutions Approval to be discussed in OC meeting, 2022-06-30
• Solutions Approval vote occurred, passing, on 2022-06-30
• Solutions development phase completed.
• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page

[ajnelson-nist]

PR 388 has passed its review checklist.