Need to represent a wide range of outputs from smart devices, including sensors on IoT devices. Representation should include output of sensors used to monitor health and environment. This need motivates the need to use an ontology of sensors and measurements, available in the Semantic Sensor Network Ontology (https://www.w3.org/TR/vocab-ssn/). Measurement units can be represented using the QUDT (http://www.qudt.org/).
Requirements
Requirement 1
UCO must be able to represent various types of repeatable measurements, including activity (e.g., walking), state (e.g., temperature), and distance.
Requirement 2
The SOSA ontology defines a class sosa:Sensor that appears to meet UCO needs of making measurements. UCO must make an ontological joining point relating observable:Device and sosa:Sensor.
E.g. if UCO makes a class observable:Sensor that is a subclass of both observable:Device and sosa:Sensor, UCO's observable:Sensor would gain all of the expressiveness from both subclass hierarchies.
Requirement 3
The sosa:Observation class is defined as the act of estimating or calculating a value of a property of a feature of interest. UCO has a class observable:Observation that to date has not been demonstrated in any public example, and its only hint of usage is being an action:Action subclass.
Requirement: UCO must align its observable:Observation class with the sosa:Observation. If observable:Observation remains a subclass of action:Action, then either guidance, or ontology-joining subproperties, must be provided to align properties that share matching purpose, especially sosa:hasResult with action:Result, and sosa:madeBySensor with a constrained action:instrument.
Risk / Benefit analysis
The use of an existing ontology elevates shared comprehension of Sensors, Observations, Samples, and Actuators across domains.
For CASE users: Integrating SOSA/SSN/QUDT concepts into UCO's subclass hierarchy would tie sosa:Observations to CASE's chain of custody.
Benefits
Adoption of SSN/SOSA/QUDT expands UCO's ability to represent a wider range of event log formats, including sensor data.
Risks
This proposal entails importing the Semantic Sensor Network (SSN) Ontology. Existing isolated representation of sensor data will have to be adapted to align with the SSN ontology.
SHACL shapes do not seem to be available for SSN or SOSA. UCO would need to implement minimal viable shapes to support users.
QUDT does provide SHACL shapes, under active development, with a recent version here. While this could be considered a UCO labor savings, the QUDT implementation includes several OWL imports that make adoption of QUDT SHACL require review of the transitive closure for breaking issues.
One risk at quick glance is that SKOS is imported from its unversioned IRI <http://www.w3.org/2004/02/skos/core>, rather than a versionIRI that was implemented to support OWL 2 DL. An update in SKOS describing a later phase of this versioned IRI is here. While this remains an issue, importing QUDT risks causing a breaking issue for UCO OWL 2 DL users.
The property sosa:hasFeatureOfInterest is likely to cause significant design discussion on what a "Feature" is within UCO's domain. The Ontology Committee is strongly encouraged to review the SOSA iPhone barometer example.
The property sosa:resultTime , as demonstrated in the iPhone barometer example, may appear to violate OWL 2 DL. The property is demonstrated as an DatatypeProperty on <Observation/346344>, and an ObjectProperty on <Observation/346345>. This appears to be an error in the documentation, as the ontology definition file designates resultTime a DatatypeProperty. The error has been raised. UCO should assume it is anowl:DatatypeProperty.
Competencies demonstrated
Competency 1
Represent a device being unlocked by an authenticated user. This type of event can be significant when individuals deny responsibility for device usage, such as texting while driving at the time of a fatal accident.
Claim: I was not texting while driving, the screen must have been activated accidentally by the screen rubbing against the car seat fabric.
Competency Question 1.1
Did the user unlock the device with biometric authentication (fingerprint) during the time of interest?
Result 1.1
Query returns all biometric authentication unlock events during the time of interest.
Competency 2
Represent a device being unlocked by an authenticated user. This type of event can be significant when individuals deny responsibility for device usage, such as texting while driving at the time of a fatal accident.
Claim: I was not texting while driving, the screen must have been activated accidentally by the screen rubbing against the car seat fabric.
Competency Question 2.1
Represent activity sensor measurements such as health tracking information.
Result 2.1
How many steps did the user take during the time of interest?
Competency 3
Represent the value of a cryptowallet as a measurement of the value of a given cryptocurrency at a specific time.
Competency Question 3.1
What was the balance amount of the cryptowallet at a specific time?
Result 3.1
Query returns the balance amount of the cryptowallet at the time of interest
Solution suggestion
Implement a class observable:Sensor, a subclass of sosa:Sensor and observable:Device.
Implement SHACL shapes minimally necessary to support observable:Sensor.
Import QUDT OR develop SHACL shapes minimally necessary to support UCO's usage of QUDT.
Make observable:Observation a subclass of sosa:Observation. Recon
A UCO observable:Observation could be multi-classed as a sosa:Observation (which, on quick review, is only a subclass of owl:Thing, so might not be so difficult to import into UCO).
Background
Need to represent a wide range of outputs from smart devices, including sensors on IoT devices. Representation should include output of sensors used to monitor health and environment. This need motivates the need to use an ontology of sensors and measurements, available in the Semantic Sensor Network Ontology (https://www.w3.org/TR/vocab-ssn/). Measurement units can be represented using the QUDT (http://www.qudt.org/).
Requirements
Requirement 1
UCO must be able to represent various types of repeatable measurements, including activity (e.g., walking), state (e.g., temperature), and distance.
Requirement 2
The SOSA ontology defines a class
sosa:Sensorthat appears to meet UCO needs of making measurements. UCO must make an ontological joining point relatingobservable:Deviceandsosa:Sensor.E.g. if UCO makes a class
observable:Sensorthat is a subclass of bothobservable:Deviceandsosa:Sensor, UCO'sobservable:Sensorwould gain all of the expressiveness from both subclass hierarchies.Requirement 3
The
sosa:Observationclass is defined as the act of estimating or calculating a value of a property of a feature of interest. UCO has a classobservable:Observationthat to date has not been demonstrated in any public example, and its only hint of usage is being anaction:Actionsubclass.Requirement: UCO must align its
observable:Observationclass with thesosa:Observation. Ifobservable:Observationremains a subclass ofaction:Action, then either guidance, or ontology-joining subproperties, must be provided to align properties that share matching purpose, especiallysosa:hasResultwithaction:Result, andsosa:madeBySensorwith a constrainedaction:instrument.Risk / Benefit analysis
sosa:Observations to CASE's chain of custody.Benefits
Adoption of SSN/SOSA/QUDT expands UCO's ability to represent a wider range of event log formats, including sensor data.
Risks
<http://www.w3.org/2004/02/skos/core>, rather than aversionIRIthat was implemented to support OWL 2 DL. An update in SKOS describing a later phase of this versioned IRI is here. While this remains an issue, importing QUDT risks causing a breaking issue for UCO OWL 2 DL users.sosa:hasFeatureOfInterestis likely to cause significant design discussion on what a "Feature" is within UCO's domain. The Ontology Committee is strongly encouraged to review the SOSA iPhone barometer example.sosa:resultTime, as demonstrated in the iPhone barometer example, may appear to violate OWL 2 DL. The property is demonstrated as anDatatypePropertyon<Observation/346344>, and anObjectPropertyon<Observation/346345>. This appears to be an error in the documentation, as the ontology definition file designatesresultTimeaDatatypeProperty. The error has been raised. UCO should assume it is anowl:DatatypeProperty.Competencies demonstrated
Competency 1
Represent a device being unlocked by an authenticated user. This type of event can be significant when individuals deny responsibility for device usage, such as texting while driving at the time of a fatal accident. Claim: I was not texting while driving, the screen must have been activated accidentally by the screen rubbing against the car seat fabric.
Competency Question 1.1
Did the user unlock the device with biometric authentication (fingerprint) during the time of interest?
Result 1.1
Query returns all biometric authentication unlock events during the time of interest.
Competency 2
Represent a device being unlocked by an authenticated user. This type of event can be significant when individuals deny responsibility for device usage, such as texting while driving at the time of a fatal accident. Claim: I was not texting while driving, the screen must have been activated accidentally by the screen rubbing against the car seat fabric.
Competency Question 2.1
Represent activity sensor measurements such as health tracking information.
Result 2.1
How many steps did the user take during the time of interest?
Competency 3
Represent the value of a cryptowallet as a measurement of the value of a given cryptocurrency at a specific time.
Competency Question 3.1
What was the balance amount of the cryptowallet at a specific time?
Result 3.1
Query returns the balance amount of the cryptowallet at the time of interest
Solution suggestion
observable:Sensor, a subclass ofsosa:Sensorandobservable:Device.observable:Sensor.observable:Observationa subclass ofsosa:Observation. Recon A UCO observable:Observation could be multi-classed as a sosa:Observation (which, on quick review, is only a subclass of owl:Thing, so might not be so difficult to import into UCO).Coordination