Add Qualities to UCO

Question

Add Qualities to UCO

ajnelson-nist opened this issue 2 years ago · 9 comments

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: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:

The CASE proposal for CryptoWalletFacet presents a need to represent the balance of a wallet.
The UCO proposal for ReactionsListFacet presents a need to characterize the vector of reacts (e.g. N hearts, M angry faces).
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.

Risk / Benefit analysis

Benefits

Consistency with other ontologies

Qualities exist in these other ontologies:

Basic Formal Ontology, BFO (a top-level ontology): obo:BFO_0000019
(gentle) Unified Foundational Ontology, gUFO (a top-level ontology): gufo:Quality
SOSA/SSN (a mid-level ontology): sosa:ObservableProperty and sosa: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: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:

kb:Observation-e0d6e355-d561-40c6-bfb3-993c0f96f769
	a
		sosa:Observation ,
		case-investigation:InvestigativeAction
		uco-observable:Observation ,
		;
	sosa:hasFeatureOfInterest kb:File-c80e6d3c-f2a2-4e39-bff3-52cd40ed7f1f ;
	sosa:hasResult kb:Hash-bb622458-c52c-4428-b832-34658c4018d7 ;
	sosa:observedProperty kb:FileContentHashQuality-a8bf6647-64fe-44e8-b1ab-e3a186e137e0 ;
	sosa:resultTime "2022-02-15T15:00:00-05:00"^^xsd:dateTime ;
	uco-action:endTime "2022-02-15T15:00:00-05:00"^^xsd:dateTime ;
	uco-action:object kb:File-c80e6d3c-f2a2-4e39-bff3-52cd40ed7f1f ;
	uco-action:result kb:ProvenanceRecord-0bce3f26-4fc4-46dd-a21e-1137e901d0c1 ;
	uco-action:startTime "2022-02-15T14:55:00-05:00"^^xsd:dateTime ;
	.
kb:ProvenanceRecord-0bce3f26-4fc4-46dd-a21e-1137e901d0c1
	a case-investigation:ProvenanceRecord ;
	uco-core:object kb:File-c80e6d3c-f2a2-4e39-bff3-52cd40ed7f1f ;
	.
kb:Hash-bb622458-c52c-4428-b832-34658c4018d7
	a uco-types:Hash ;
	uco-types:hashMethod "SHA3-256"^^uco-vocabulary:HashNameVocab ;
	uco-types:hashValue "a78f2c566b2439463a2e7ca515bbfa3f92948506583cbadaebdd507f277542bd"^^xsd:hexBinary ;
	.

(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?

SELECT ?lResultTime ?lHashValue
WHERE {
	?nObservation
		a sosa:Observation ;
		sosa:resultTime ?lResultTime ;
		sosa:hasFeatureOfInterest
		  / uco-core:hasFacet
		    / uco-observable:hash
		      / uco-types:hashValue ?lHashValue ;
		.
}
ORDER BY ?lResultTime

Result 1.1

?lResultTime	?lHashValue
2022-01-15T09:05:00-05:00	a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
[...]	[...]
2022-01-31T23:05:00-05:00	a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
[...]	[...]
2022-02-08T23:05:00-05:00	a78f2c566b2439463a2e7ca515bbfa3f92948506583cbadaebdd507f277542bd
[...]	[...]
2022-02-15T15:00:00-05:00	a78f2c566b2439463a2e7ca515bbfa3f92948506583cbadaebdd507f277542bd

Solution suggestion

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:

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 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.

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

Tracking in Jira ticket OC-292
Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-04-11
Requirements to be discussed in OC meeting, 2023-04-18
Requirements Review vote has not occurred

Requirements development phase completed.
Solution announced to OCs on TODO-date
Solutions Approval to be discussed in OC meeting, date TBD
Solutions Approval vote has not occurred

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 (or N/A)
Milestone linked
Documentation logged in pending release page

Answer 1 · 2023-04-11T20:16:15.000Z

One thing missing from the original post is a design for Requirement 3, how to migrate current Facet-housed properties to Qualitys. The Solution Suggestion in the Issue will be updated to incorporate definitions in this comment.

Let's take observable:clockSetting on observable:MobileDeviceFacet (with range xsd:dateTime) as an exemplar, as I imagine we won't have any staunch defenders of declaring this as a fixed-value property. (Its definition seems to run afoul of the intent of ObservableObjects noted in this Issue's background.)

The most straightforward path to migrating this from a owl:DatatypeProperty used in observable:MobileDeviceFacet to a core:Quality would be:

Wholly deprecate observable:clockSetting, as done previously for observable:creationTime.
Define a subclass of core:Quality, observable:ClockSettingQuality.
Bind observable:ClockSettingQuality to observable:MobileDevice through use of a qualified property association.

In OWL, this would mean adding to observable.ttl:

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.ttl:

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 data

Suppose 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 MobileDeviceFacet into a quality-value, we need to define a property to hold the quality-value. Rather than associate the quality-value with the object, we associate it with the quality.

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 DatatypeProperty's range locally within the ClockSettingQuality class. Similar restrictions can be done for core:hadObjectQualityValue.

# 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 QualityValue to be used instead of the literal, should UCO adopt or implement a reified temporal instant class in the future. It is still possible to implement a requirement that only a literal quality value or object quality value be used; take for example this block doing so for FileContentHashQuality, disallowing literals:

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 clockSetting migration: Switching to a Quality and removing the Facet-housed property, this is how the JSON would now look:

{
    "@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 (hadXQualityValue):

It allows a "shortcut" representation, masking that there was some observation process---or potentially multiple---that yielded the quality-value.
The spelling removes a designation of a "current" value. If there's only one value in the graph, then that value is current. (Though, without the observation also being in the graph, it's unknown how long ago, or how frequently, that "current" value was observed.)

For use cases where only a floor and ceiling of one quality-value is needed, the spelling hadXQualityValue meets the need.

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 Observation action yielding the quality-value.

Solution alignments

These sections describe how the proposed core:hadXQualityValue properties could align with other ontologies that provide Qualitys.

BFO

With the mapping of QualityValue to BFO unclear (see obo:IAO_0000109) note above, it is unclear how the quality-value assignments would map.

gUFO

The gUFO mapping takes the shortened quality-value assignment property, and maps it forward through some gufo:QualityValueAttributionSituation, then to the value with gufo:concernsReifiedQualityValue (object) or gufo:concernsQualityValue (literal).

Though the OWL inference mechanisms handle this implication automatically, there is one mapping point worth describing: This property chain axiom assumes that the Quality stands in the gufo:QualityValueAttributionSituation, rather than the gufo:Endurant in which the Quality inheres. gUFO Situations permit any gufo:Endurant to stand therein.

core:hadLiteralQualityValue                                                                                        
        owl:propertyChainAxiom (
                gufo:standsInQualfiedAttribution                                                                       
                gufo:concernsQualityValue                                                                              
        ) ;             
        .       
                
core:hadObjectQualityValue                                                                                         
        owl:propertyChainAxiom (
                gufo:standsInQualfiedAttribution                                                                       
                gufo:concernsReifiedQualityValue                                                                       
        ) ;                                                                                                            
        .

SOSA/SSN

The SOSA/SSN mapping takes the shortened quality-value assignment property, and maps it back through some sosa:Observation observing it, then forward from the sosa:Observation via sosa:hasSimpleResult (literal) or sosa:hasResult (object).

A note for future development: The propertyChainAxiom spelled here can't also be compatible with sosa:actsOnProperty for sosa:Actuations. This might induce hadObjectQualityValue to be named hadObservedObjectQualityValue (likewise for hadLiteralQualityValue) instead, if UCO were to move toward adopting SOSA/SSN and/or make a class mappable to sosa:Actuation.

drafting:hadLiteralQualityValue
        owl:propertyChainAxiom (
                [
                        owl:inverseOf sosa:observedProperty ;
                ]
                sosa:hasSimpleResult
        ) ;
        . 

drafting:hadObjectQualityValue
        owl:propertyChainAxiom (
                [
                        owl:inverseOf sosa:observedProperty ;
                ]
                sosa:hasResult
        ) ;
        .

Answer 2 · 2023-04-11T20:29:44.000Z

On Requirement 4 (relating Qualitys to current Facet-housed properties), I am not quite sure what more would e beneficial beyond a custom owl:AnnotationProperty that links a Quality to a owl:ObjectProperty or owl:DatatypeProperty; something like core:correspondsWithFixedValueProperty? Feedback is welcome on whether that should remain a requirement for this proposal.

Consider FileContentHashQuality from the initial post, and how it would pertain to observable:hash.

Also, if not clear, this change proposal only includes FileContentHashQuality for illustration, and is not proposing adopting that Quality at the same time as defining UCO's general Quality.

Answer 3 · 2023-04-13T09:59:27.000Z

Two points of critique:

I'd like to suggest the relationship between a Quality and the Object it belongs to, be one of inherence, i.e., to underline the principle that the Quality is in its existence dependent on the availability of the Object. Indeed, I'm biased in my view through (g)UFO, but I think this is a necessary principle to formulate: the redness of the apple disappears when the apple has been eaten.
Again, according to (g)UFO, the inherence relationship should not have an inverse in order to underline that the particular redness of the apple is unique to that apple. Rational: The quality is uniquely instantiated for the object that it inheres in: there is no other object that shares the same instantiated redness. Two objects, of course, can have a quality value that is "equal", e.g., they show the same redness. But this does not imply that they share the same instance of the quality value! The apple that is red today, will be brown tomorrow. Hence, if they would share the same quality value, then their color would degrade in exactly the same manner over time, and this is clearly not the case. Furthermore, a unique instantiated quality value allows for a single method to establish equivalence of the quality values of the objects: when the Euclidian distance between the two values is within a certain limit they are considered equivalent, provided consideration on accuracy and resolution of the value ranges.

Hence, in short:

Remove core:hasQuality from the proposal;
Change core:isQualityOf to core:inheresIn, and reject any inversOf property.

Answer 4 · 2023-04-13T10:11:17.000Z

Why are the relationships between core:Quality and core:QualityValue expressed in the past tense: core:hadLiteralQualityValue and core:hadObjectQualityValue?

Answer 5 · 2023-04-13T12:33:47.000Z

Editorial note: I've revised the "Solution suggestion" section to remove a note that approximately read "This proposal doesn't describe how to associate QualityValues." As of the first comment after the Issue, that part of the solution is suggested.

Answer 6 · 2023-04-13T12:48:31.000Z

Why are the relationships between core:Quality and core:QualityValue expressed in the past tense: core:hadLiteralQualityValue and core:hadObjectQualityValue?

@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 hasLiteralQualityValue (likewise for hasObjectQualityValue) implies that the quality value is, for all times that triple remains in the graph, X. If Y is observed to be the value, then we have:

kb:SocialMediaPost-842fe9bf-10bf-4441-97e5-31f0778f4ae7
    a ex:SocialMediaPost ;
    core:hasQuality ex:ThumbsUpLikeCountQuality-f9fc28fb-bfa9-4c90-b986-aa989c8609e6 ;
    .

ex:ThumbsUpLikeCountQuality-f9fc28fb-bfa9-4c90-b986-aa989c8609e6
    a ex:ThumbsUpLikeCountQuality ;
    core:hasLiteralQualityValue
        2 ,
        19854,
        946456
        ;
     .

So, with that spelling, the Quality simultaneously has 2, 20k, and 950k Likes.

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 Observations, no matter how they're represented, to find times to determine the growth rate. And again, providing the had...QualityValue properties at all is to provide a shortcut if the application opts to not make objects to represent the Observations.

Personally, I would rather enforce the Observations be represented, but it would not be necessary for some applications such as those providing statistical summarization and needing to feed a more compact data model. Also, I am concerned that this proposal has enough going on as-is, and bringing in finally exercising UCO's yet-unexercised Observation class might be too much. I also think making the tie to the Observation class is a separable proposal. But if Ontology Committee members want Observation to be shored up as part of this proposal, I'm fine incorporating that.

Answer 7 · 2023-04-13T12:57:55.000Z

Two points of critique:

I'd like to suggest the relationship between a Quality and the Object it belongs to, be one of inherence, i.e., to underline the principle that the Quality is in its existence dependent on the availability of the Object. Indeed, I'm biased in my view through (g)UFO, but I think this is a necessary principle to formulate: the redness of the apple disappears when the apple has been eaten.

Again, according to (g)UFO, the inherence relationship should not have an inverse in order to underline that the particular redness of the apple is unique to that apple. Rational: The quality is uniquely instantiated for the object that it inheres in: there is no other object that shares the same instantiated redness. Two objects, of course, can have a quality value that is "equal", e.g., they show the same redness. But this does not imply that they share the same instance of the quality value! The apple that is red today, will be brown tomorrow. Hence, if they would share the same quality value, then their color would degrade in exactly the same manner over time, and this is clearly not the case. Furthermore, a unique instantiated quality value allows for a single method to establish equivalence of the quality values of the objects: when the Euclidian distance between the two values is within a certain limit they are considered equivalent, provided consideration on accuracy and resolution of the value ranges.

Hence, in short:

Remove core:hasQuality from the proposal;

Change core:isQualityOf to core:inheresIn, and reject any inversOf property.

@plbt5 : With some irony, the reason I provided the inverted spelling of core:hasQuality was to enable alignment with gUFO for those who choose to use UCO and gUFO. In the solution sketch in the initial Issue posting, I included this snippet to show how the new classes and properties could align with gUFO:

# 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 core:isQualityOf should be a owl:FunctionalProperty. I had designated it so, and like we do with core:hasFacet, core:hasQuality is designated an owl:InverseFunctionalProperty.

I also have a brief response on inverseOf, but have to wait for a meeting starting in a few minutes.

Answer 8 · 2023-04-13T17:31:37.000Z

(I apologize for cursing this comment by predicting it would be brief.)

@plbt5 : In response to the suggestion to change core:isQualityOf to core:inheresIn: I see where you are coming from specifically with gUFO, because of the property gufo:inheresIn. I have already shown how an alignment with gUFO could have core:isQualityOf be a subproperty of gufo:inheresIn.

I do not think it would be appropriate to switch core:isQualityOf to core:inheresIn, because of the rdfs:domain specificity. Relatedly, I do think it would eventually be appropriate to start a subproperty hierarchy, with core:inheresIn defined, and core:isQualityOf benefitting, like so:

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 core:hasFacet, core:isFacetOf, I would take that as sufficient motivation to start the hierarchy.

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 rdfs:subPropertyOf across that same page finding nothing, whereas rdfs:subClassOf shows up in some key recursive operations. So, with subproperty support delegated to RDFS and/or OWL entailment, starting down the road of subproperties means we would need to set some quality control rules and be overly explicit. That should happen in a future proposal.

Hence, I intend to leave the proposal as adding core:isQualityOf instead of core:inheresIn.

I also suggest keeping the inverse, core:hasQuality, because of the parallel with core:hasFacet.

Have I answered your concerns?

Answer 9 · 2023-04-13T17:38:33.000Z

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, types:threadPredecessor and types:threadPreviousItem.

As a point of keeping UCO potentially interoperable with other ontologies, we should be prepared to make use of OWL features.