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
At a recent UCO workshop, somebody raised a design point in UCO that had been intended since UCO's inception and before, but unfortunately had been forgotten. The point is roughly that "In UCO, an Observable Object must provide the same observed property-values, regardless of the context of how the object was observed." In particular, among the interpreting agent (whether a person or software), the analytic environment, the time of the observation, and other influential factors in the act of observing and describing something: nothing should differ about the ObservableObject's recorded characteristics, except for possibly the IRI. (Complete sets of keying characteristics are deeply specific to each class, making deterministic UUIDs a logistical challenge.)
UCO currently does not adhere to this principle in several properties, which can be realized quickly to be liable to differ between observations at two times:
observable:isActive on observable:AccountFacet
observable:owner on observable:AccountFacet
observable:clockSetting on observable:MobileDeviceFacet
observable:uptime on observable:ComputerSpecificationFacet
Further, several proposals have come raising the need for time-influenced observed values of properties:
Under some interpretations of observable:File, the set of associated hashes is not fixed and can be context-dependent. (This proposal is pending, though a good chunk of it appears as examples in this proposal.)
These varying properties are known as Qualities in some Top-Level Ontologies. Another mid-level ontology, referenced starting in the Benefits section, maintains calling them Properties, but for the remainder of this Issue they will be called Qualitys to avoid overloading with OWL Propertys.
UCO needs to adopt the idea of Qualities, at least to move towards contextual independence of ObservableObject characterizations.
Requirements
Requirement 1
For certain observable properties, aka Qualities, that are known to vary, UCO MUST be able to hold, within the same graph, that for one object, its instance of a Quality was observed to have different values at different times. (For instance, a social media post could have 2 Reacts one day, 2 million Reacts a day after going viral.)
Requirement 2
UCO MUST be able to represent how a value of a Quality was observed.
Requirement 3
UCO MUST establish a path forward to move current non-invariant, Facet-housed properties of ObservableObjects to a Quality-based implementation.
Requirement 4
UCO MUST support a mechanism to relate Qualities to (Facet-housed) properties that are expected to be fixed-value.
Requirement 5
UCO MUST be able to support quality values that are both literal-valued and object-valued. E.g. a quality representing a running computer's boot time should be able to support a literal xsd:dateTime as a value; and the quality representing a file's hash should be able to have a types:Hash object as a value.
Requirement 6
UCO SHOULD define Qualities to enable alignment with other ontologies, top-level and/or mid-level, that already have modeled Qualities.
One significant motivation for Requirement 4 is file hash review. In some operational contexts, certain files are expected to not change contents. A Quality representing the file's contents can be used to show that the file's hash was observed to remain consistent before, during, and after an analysis process.
Currently, it seems the only available UCO mechanism to review a file's hashes is to create a new observable:File object (new IRI), redundantly recording its property-values for match-review. This can cause significant confusion in chain of custody handling. If a file is hashed before each of five steps, did the analysis really entail five files corresponding with the five observable:Files?
Risks
Qualities significantly increase graph object interconnectedness. This appears to be a necessary "tax" on explaining how values were observed.
Counter to this risk, there is significant value in showing that multiple observations with variances in execution find the same value.
Qualities introduce a decision point in all future property discussion, on whether the property is a quality, or something closer to an inherent, invariant characteristic of an object.
Augmenting this risk, UCO would need to do the same for its current suite of properties, at least under the observable namespace.
Counter to this risk, UCO has not made this distinction to date, and this will provide a significant advancement to identifying properties that are essential to objects.
The submitter recommends Qualities be attached to UcoObject subclasses, and not Facets. No other reviewed ontology that provides Qualities has a concept like Facet, so attempting to make an alignment of another ontology's Quality with a Facet-housed Quality would be significantly difficult.
Competencies demonstrated
Competency 1
A file is characterized at the start of an analysis that, by design and organizational mandate, should not modify the file.
kb:File-c80e6d3c-f2a2-4e39-bff3-52cd40ed7f1f
a uco-observable:File ;
uco-core:objectCreatedTime "2022-01-15T09:00:00-05:00"^^xsd:dateTime ;
uco-core:hasFacet kb:ContentDataFacet-20fd04aa-9ba3-45c4-aace-2a97f6b23d70 ;
.
kb:ContentDataFacet-20fd04aa-9ba3-45c4-aace-2a97f6b23d70
a uco-observable:ContentDataFacet ;
uco-observable:hash kb:Hash-bb622458-c52c-4428-b832-34658c4018d7 ;
.
kb:Hash-bb622458-c52c-4428-b832-34658c4018d7
a uco-types:Hash ;
uco-types:hashMethod "SHA3-256"^^uco-vocabulary:HashNameVocab ;
uco-types:hashValue "a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a"^^xsd:hexBinary ;
.
A quality representing the file's content hash is defined.
drafting:FileContentHashQuality
a owl:Class ;
rdfs:subClassOf drafting:Quality ;
.
kb:FileContentHashQuality-a8bf6647-64fe-44e8-b1ab-e3a186e137e0
a drafting:FileContentHashQuality ;
drafting:isQualityOf kb:File-c80e6d3c-f2a2-4e39-bff3-52cd40ed7f1f ;
.
The analysis takes a month, and many operations are done against that file. Periodically, the file is hashed with a scripted check, and the script records the hash measurement using SOSA Observations. The analyst finishes the work, runs one last hash operation and sees the following:
Note 1: This solution sketch initially did not include a tie between Quality and QualityValue. The sketch was since updated to include that tie, in the first comment following this initial post.
Note 2: The demonstration of Observations using SSN/SOSA is known to differ in structure from a similarly-purposed representation of Observations in gUFO. gUFO does not have a class to directly represent an "Observation" as SSN/SOSA does; instead, the quality value is tied with a gufo:Situation. Differences in other ontologies' representations on tying quality values to the domain object are why this proposal only goes so far as defining "shortcut" properties hadLiteralQualityValue and hadObjectQualityValue. Multiple options exist, through external ontologies, to further characterize how quality values would to the quality.
Define new classes, core:Quality and core:QualityValue:
core:Quality
a owl:Class ;
rdfs:subClassOf core:UcoInherentCharacterizationThing ;
.
core:QualityValue
a owl:Class ;
rdfs:subClassOf core:UcoInherentCharacterizationThing ;
.
Define a new property, and inverse, to relate a Quality to a UcoObject:
Define a new property to relate a QualityValue to a Quality. A full description of rationale is in the first comment in this Issue.
core:hadLiteralQualityValue
a owl:DatatypeProperty ;
rdfs:comment "This property intentionally has an unrestricted range."@en ;
rdfs:domain core:Quality ;
.
core:hadObjectQualityValue
a owl:ObjectProperty ;
rdfs:domain core:Quality ;
rdfs:range core:QualityValue ;
.
Though it is not current UCO style to do so, the proposer would like to also include this general-purpose shape, detached from any owl:Class. Else, every sh:PropertyShape constraining core:hadObjectQualityValue would need to include core:QualityValue in the sh:class constraint, as well as the further-constrained class. (e.g. for FileContentHashQuality, the constraint would read sh:class core:QualityValue, types:Hash.)
core:hadObjectQualityValue-range-shape
a sh:NodeShape ;
rdfs:comment """
Note for illustration: This shape is defined to save on making
redundant sh:class assignments in classes' node shapes.
"""@en ;
sh:class core:QualityValue ;
sh:nodeKind sh:IRI ;
sh:targetObjectsOf core:hadObjectQualityValue ;
.
Solution alignments
The proposed solution has the following potential alignments for profiles of UCO usage where the other ontology is treated as a higher-level basis.
The first comment in this Issue has further mappings for assignment of QualityValues to Qualitys.
BFO
obo:BFO_0000019 rdfs:label "quality"@en .
core:Quality
rdfs:subClassOf obo:BFO_0000019 ;
.
# It does not appear that BFO directly provides a suitable class for
# alignment with core:QualityValue.
# Potentially, the Information Artifact Ontology does,
# 'measurement datum', indirectly noted in the BFO 2.0 Specification
# and User's Guide.
# http://purl.obolibrary.org/obo/IAO_0000109
obo:BFO_0000159 rdfs:label "has quality at all times"@en .
core:hasQuality
rdfs:subPropertyOf obo:BFO_0000159 ;
.
obo:BFO_0000080 rdfs:label "quality of at all times"@en .
core:isQualityOf
rdfs:subPropertyOf obo:BFO_0000080 ;
.
gUFO
core:Quality
rdfs:subClassOf gufo:Quality ;
.
core:QualityValue
a gufo:AbstractIndividualType ;
rdfs:subClassOf gufo:QualityValue ;
.
# gUFO does not define an inverse property for gufo:inheresIn .
core:isQualityOf
rdfs:subPropertyOf gufo:inheresIn ;
.
SOSA/SSN
Note that with the definitions of ssn:FeatureOfInterest, ssn:hasProperty and ssn:isPropertyOf, core:Qualitys aligned as in the following block would be predicated on the existence of some (SOSA) Observation focused on the attached sosa:FeatureOfInterest (or Actuation focused on modifying the quality value). This dependence appears to be an addition over the alignments from BFO and gUFO, where a quality inheres only in some endurant, and does not further need any process observing that endurant. This dependence does not necessarily require, via a SHACL shape, that such an Observation be in the graph.
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
At a recent UCO workshop, somebody raised a design point in UCO that had been intended since UCO's inception and before, but unfortunately had been forgotten. The point is roughly that "In UCO, an Observable Object must provide the same observed property-values, regardless of the context of how the object was observed." In particular, among the interpreting agent (whether a person or software), the analytic environment, the time of the observation, and other influential factors in the act of observing and describing something: nothing should differ about the
ObservableObject's recorded characteristics, except for possibly the IRI. (Complete sets of keying characteristics are deeply specific to each class, making deterministic UUIDs a logistical challenge.)UCO currently does not adhere to this principle in several properties, which can be realized quickly to be liable to differ between observations at two times:
observable:isActiveonobservable:AccountFacetobservable:owneronobservable:AccountFacetobservable:clockSettingonobservable:MobileDeviceFacetobservable:uptimeonobservable:ComputerSpecificationFacetFurther, several proposals have come raising the need for time-influenced observed values of properties:
CryptoWalletFacetpresents a need to represent the balance of a wallet.ReactionsListFacetpresents a need to characterize the vector of reacts (e.g. N hearts, M angry faces).observable:File, the set of associated hashes is not fixed and can be context-dependent. (This proposal is pending, though a good chunk of it appears as examples in this proposal.)These varying properties are known as Qualities in some Top-Level Ontologies. Another mid-level ontology, referenced starting in the Benefits section, maintains calling them Properties, but for the remainder of this Issue they will be called
Qualitys to avoid overloading with OWLPropertys.UCO needs to adopt the idea of Qualities, at least to move towards contextual independence of
ObservableObjectcharacterizations.Requirements
Requirement 1
For certain observable properties, aka Qualities, that are known to vary, UCO MUST be able to hold, within the same graph, that for one object, its instance of a Quality was observed to have different values at different times. (For instance, a social media post could have 2 Reacts one day, 2 million Reacts a day after going viral.)
Requirement 2
UCO MUST be able to represent how a value of a Quality was observed.
Requirement 3
UCO MUST establish a path forward to move current non-invariant,
Facet-housed properties ofObservableObjects to a Quality-based implementation.Requirement 4
UCO MUST support a mechanism to relate Qualities to (
Facet-housed) properties that are expected to be fixed-value.Requirement 5
UCO MUST be able to support quality values that are both literal-valued and object-valued. E.g. a quality representing a running computer's boot time should be able to support a literal
xsd:dateTimeas a value; and the quality representing a file's hash should be able to have atypes:Hashobject as a value.Requirement 6
UCO SHOULD define Qualities to enable alignment with other ontologies, top-level and/or mid-level, that already have modeled Qualities.
Risk / Benefit analysis
Benefits
Consistency with other ontologies
Qualities exist in these other ontologies:
obo:BFO_0000019sosa:ObservablePropertyandsosa:ActuatableProperty(the latter handling qualities that one modifies rather than observes)Fixity review
One significant motivation for Requirement 4 is file hash review. In some operational contexts, certain files are expected to not change contents. A Quality representing the file's contents can be used to show that the file's hash was observed to remain consistent before, during, and after an analysis process.
Currently, it seems the only available UCO mechanism to review a file's hashes is to create a new
observable:Fileobject (new IRI), redundantly recording its property-values for match-review. This can cause significant confusion in chain of custody handling. If a file is hashed before each of five steps, did the analysis really entail five files corresponding with the fiveobservable:Files?Risks
Qualities significantly increase graph object interconnectedness. This appears to be a necessary "tax" on explaining how values were observed.
Qualities introduce a decision point in all future property discussion, on whether the property is a quality, or something closer to an inherent, invariant characteristic of an object.
observablenamespace.The submitter recommends Qualities be attached to
UcoObjectsubclasses, and notFacets. No other reviewed ontology that provides Qualities has a concept likeFacet, so attempting to make an alignment of another ontology's Quality with aFacet-housed Quality would be significantly difficult.Competencies demonstrated
Competency 1
A file is characterized at the start of an analysis that, by design and organizational mandate, should not modify the file.
A quality representing the file's content hash is defined.
The analysis takes a month, and many operations are done against that file. Periodically, the file is hashed with a scripted check, and the script records the hash measurement using SOSA Observations. The analyst finishes the work, runs one last hash operation and sees the following:
(Other
Observations were not typed here, but please assume they are also in the graph.)Competency Question 1.1
What is the timeline of Observations of the hash values?
Result 1.1
Solution suggestion
Note 1: This solution sketch initially did not include a tie between
QualityandQualityValue. The sketch was since updated to include that tie, in the first comment following this initial post.Note 2: The demonstration of
Observations using SSN/SOSA is known to differ in structure from a similarly-purposed representation ofObservations in gUFO. gUFO does not have a class to directly represent an "Observation" as SSN/SOSA does; instead, the quality value is tied with agufo:Situation. Differences in other ontologies' representations on tying quality values to the domain object are why this proposal only goes so far as defining "shortcut" propertieshadLiteralQualityValueandhadObjectQualityValue. Multiple options exist, through external ontologies, to further characterize how quality values would to the quality.Define new classes,
core:Qualityandcore:QualityValue:Define a new property, and inverse, to relate a
Qualityto aUcoObject:Define a new property to relate a
QualityValueto aQuality. A full description of rationale is in the first comment in this Issue.Though it is not current UCO style to do so, the proposer would like to also include this general-purpose shape, detached from any
owl:Class. Else, everysh:PropertyShapeconstrainingcore:hadObjectQualityValuewould need to includecore:QualityValuein thesh:classconstraint, as well as the further-constrained class. (e.g. forFileContentHashQuality, the constraint would readsh:class core:QualityValue, types:Hash.)Solution alignments
The proposed solution has the following potential alignments for profiles of UCO usage where the other ontology is treated as a higher-level basis.
The first comment in this Issue has further mappings for assignment of
QualityValues toQualitys.BFO
gUFO
SOSA/SSN
Note that with the definitions of
ssn:FeatureOfInterest,ssn:hasPropertyandssn:isPropertyOf,core:Qualitys aligned as in the following block would be predicated on the existence of some (SOSA)Observationfocused on the attachedsosa:FeatureOfInterest(orActuationfocused on modifying the quality value). This dependence appears to be an addition over the alignments from BFO and gUFO, where a quality inheres only in some endurant, and does not further need any process observing that endurant. This dependence does not necessarily require, via a SHACL shape, that such anObservationbe in the graph.Coordination