Add Qualities to UCO #535
Comments
|
One thing missing from the original post is a design for Requirement 3, how to migrate current Let's take The most straightforward path to migrating this from a
In OWL, this would mean adding to observable:MobileDevice
rdfs:subClassOf [
a owl:Restriction ;
owl:maxQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
owl:onClass observable:ClockSettingQuality ;
owl:onProperty core:hasQuality ;
] ;
.(As a reminder, since it has been some time since UCO exercised this portion of OWL, the primer section 5.3 demonstrates this syntax. Also note that document has Turtle syntax available to be displayed by clicking a button at the end of Section 1.2.) In SHACL, this would mean adding to observable:MobileDevice
sh:property [
a sh:PropertyShape ;
sh:path core:hasQuality ;
sh:qualifiedMaxCount "1"^^xsd:integer ;
sh:qualifiedValueShape [
a sh:NodeShape ;
sh:class observable:ClockSettingQuality ;
] ;
] ;
.Revising instance dataSuppose we have this instance data: {
"@context": {
"kb": "http://example.org/kb/",
"core": "https://ontology.unifiedcyberontology.org/uco/core/",
"observable": "https://ontology.unifiedcyberontology.org/uco/observable/",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
"@graph": [
{
"@id": "kb:MobileDevice-b8d17daa-3f60-4848-a6e7-dd8c9061ab16",
"@type": "observable:MobileDevice",
"core:hasFacet": {
"@id": "kb:MobileDeviceFacet-42e5c321-11f6-4cab-a1b0-dcf07702e9ea",
"@type": "observable:MobileDeviceFacet",
"observable:clockSetting": {
"@type": "xsd:dateTime",
"@value": "2018-10-31T23:59:59Z"
}
},
"core:modifiedTime": {
"@type": "xsd:dateTime",
"@value": "2023-02-01T14:00:00Z"
}
}
]
}To migrate the 2018 timestamp from 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 ;
.
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 ;
.Both OWL and SHACL offer a mechanism to constrain the # OWL
observable:ClockSettingQuality
rdfs:subClassOf [
a owl:Restriction ;
owl:allValuesFrom xsd:dateTime ;
owl:onProperty core:hadLiteralQualityValue ;
] ;
.
# SHACL
observable:ClockSettingQuality
sh:property [
a sh:PropertyShape ;
sh:datatype xsd:dateTime ;
sh:path core:hadLiteralQualityValue ;
] ;
.The above implementation so far still permits a reified observable:FileContentHashQuality
a
owl:Class ,
sh:NodeShape
;
rdfs:subClassOf
core:Quality ,
[
a owl:Restriction ;
rdfs:comment "This property-disallowance style seen in BFO."@en ;
owl:allValuesFrom owl:Nothing ;
owl:onProperty core:hadLiteralQualityValue ;
]
[
a owl:Restriction ;
owl:allValuesFrom types:Hash ;
owl:onProperty core:hadObjectQualityValue ;
]
;
sh:property
[
a sh:PropertyShape ;
rdfs:comment """
Note for illustration: This class constraint IS currently
compatible with core:hadObjectQualityValue-range-shape,
because UCO does not disallow a node
(via owl:disjointWith) from being typed both
core:QualityValue and types:Hash.
"""@en ;
sh:class uco-types:Hash ;
sh:path core:hadObjectQualityValue ;
] ,
[
a sh:PropertyShape ;
sh:maxCount "0"^^xsd:integer ;
sh:path core:hadLiteralQualityValue ;
]
;
sh:targetClass observable:FileContentHashQuality ;
.Back to the {
"@context": {
"kb": "http://example.org/kb/",
"core": "https://ontology.unifiedcyberontology.org/uco/core/",
"observable": "https://ontology.unifiedcyberontology.org/uco/observable/",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
"@graph": [
{
"@id": "kb:ClockSettingQuality-09ae086d-ab33-42a2-a489-1b8281cd735b",
"@type": "observable:ClockSettingQuality",
"core:hadLiteralQualityValue": [
{
"@type": "xsd:dateTime",
"@value": "2018-10-31T23:59:59Z"
}
]
},
{
"@id": "kb:MobileDevice-b8d17daa-3f60-4848-a6e7-dd8c9061ab16",
"@type": "observable:MobileDevice",
"core:hasQuality": {
"@id": "kb:ClockSettingQuality-09ae086d-ab33-42a2-a489-1b8281cd735b"
},
"core:modifiedTime": {
"@type": "xsd:dateTime",
"@value": "2023-02-01T14:00:00Z"
}
}
]
}There are two reasons for spelling the quality-value association properties in the past tense (
For use cases where only a floor and ceiling of one quality-value is needed, the spelling For use cases where multiple quality-values could be present, the shortcut property has the shortcoming of not knowing currency, frequency, or other descriptors of the values' applicability. For use cases where a more full representation of how the value was determined---e.g. to associate a time of observation---the representation can be delegated according to the (future w.r.t. this proposal) representation of some Solution alignmentsThese sections describe how the proposed BFOWith the mapping of gUFOThe gUFO mapping takes the shortened quality-value assignment property, and maps it forward through some Though the OWL inference mechanisms handle this implication automatically, there is one mapping point worth describing: This property chain axiom assumes that the core:hadLiteralQualityValue
owl:propertyChainAxiom (
gufo:standsInQualfiedAttribution
gufo:concernsQualityValue
) ;
.
core:hadObjectQualityValue
owl:propertyChainAxiom (
gufo:standsInQualfiedAttribution
gufo:concernsReifiedQualityValue
) ;
.SOSA/SSNThe SOSA/SSN mapping takes the shortened quality-value assignment property, and maps it back through some A note for future development: The drafting:hadLiteralQualityValue
owl:propertyChainAxiom (
[
owl:inverseOf sosa:observedProperty ;
]
sosa:hasSimpleResult
) ;
.
drafting:hadObjectQualityValue
owl:propertyChainAxiom (
[
owl:inverseOf sosa:observedProperty ;
]
sosa:hasResult
) ;
. |
|
On Requirement 4 (relating Consider Also, if not clear, this change proposal only includes |
|
Two points of critique:
Hence, in short:
|
|
Why are the relationships between |
|
Editorial note: I've revised the "Solution suggestion" section to remove a note that approximately read "This proposal doesn't describe how to associate |
@plbt5 : The reason these are spelled in the past tense is to denote that the quality-value was observed at some point to be X. X is not the only possible value; Y could be observed at some different time, or via some different observation mechanism. Spelling the property So, with that spelling, the I spelled it had because, at points in the past, it had 2, 20k, and 950k likes. It's then up to referring to the associated Personally, I would rather enforce the |
@plbt5 : With some irony, the reason I provided the inverted spelling of # gUFO does not define an inverse property for gufo:inheresIn .
core:isQualityOf
rdfs:subPropertyOf gufo:inheresIn ;
.Also, much of your second point pertains to how the proposed I also have a brief response on |
|
(I apologize for cursing this comment by predicting it would be brief.) @plbt5 : In response to the suggestion to change I do not think it would be appropriate to switch core:inheresIn
a
owl:ObjectProperty ,
owl:FunctionalProperty
;
rdfs:domain core:UcoInherentCharacterizationThing ;
rdfs:range core:UcoObject ;
.
core:isQualityOf
a
owl:ObjectProperty ,
owl:FunctionalProperty
;
rdfs:subPropertyOf core:inheresIn ;
# The domain narrows in this subproperty.
rdfs:domain core:Quality ;
# rdfs:range is inherited from inheresIn. No further narrowing required.
.However, I'm not inclined to add that to this proposal without a second motivating subproperty. If we had the inverse property for My hesitation on going with subproperties directly in UCO is that they're a little difficult to support in instance data. SHACL does not include procedures for reviewing subproperties. This isn't explicitly noted in the SHACL specification, but can be deduced from Specification Section 1.5 and a text-search of Hence, I intend to leave the proposal as adding I also suggest keeping the inverse, Have I answered your concerns? |
|
Oh, and on whether we establish a policy of rejecting inverse properties: I support keeping the option of inverse properties. UCO hadn't used them before Issue 393, but the adoption of Issue 393 includes two properties with inverses defined, As a point of keeping UCO potentially interoperable with other ontologies, we should be prepared to make use of OWL features. |
This covers the potential for Qualities (under proposal in Issue 535), which in multiple foundational ontologies are acknowledged as endurants, but in UCO would be inherent characterization things. No effects were observed on Make-managed files. References: * #535 * #544 Signed-off-by: Alex Nelson <[email protected]>
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:core:hasQuality a owl:ObjectProperty , owl:InverseFunctionalProperty ; rdfs:domain core:UcoObject ; rdfs:range core:Quality ; owl:inverseOf core:isQualityOf ; . core:isQualityOf a owl:ObjectProperty , owl:FunctionalProperty ; rdfs:domain core:Quality ; rdfs:range core:UcoObject ; owl:inverseOf core:hasQuality ; .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.core:Quality rdfs:subClassOf [ a owl:Class ; owl:unionOf ( sosa:ActuatableProperty sosa:ObservableProperty ) ] ; . core:QualityValue rdfs:subClassOf sosa:Result ; . core:hasQuality rdfs:subPropertyOf ssn:hasProperty ; . core:isQualityOf rdfs:subPropertyOf ssn:isPropertyOf ; .Coordination
developfor the next releasedevelopstate with backwards-compatible implementation merged intodevelop-2.0.0develop-2.0.0(or N/A)The text was updated successfully, but these errors were encountered: