Represent sensor outputs

[cyberinvestigationexpress]

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

Coordination

• Tracking in Jira ticket OC-247

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-06-27
• Requirements to be discussed in OC meeting, date 2022-06-30

• 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.
• Implementation has not been merged into develop

• Milestone linked
• Documentation logged in pending release page

[plbt5]

@ajnelson-nist Note that requirements 1 & 2 are not specified in a functional way but as a solution instead. Requirement 3 is much more funactionally oriented, and therefore clearer in what it is that this CP intends to achieve. Could you please rewrite Reqs. 1 & 2 into a similar functional demand?

[ajnelson-nist]

This proposal initiates adoption of part or all of SOSA, SSN, and QUDT. Interestingly, the "SHACL incubation" strategy used in UCO's Collections Ontology adoption only partially applies here. It does not appear that SSN provides SHACL shapes for SSN or SOSA, so we may have to develop SHACL shapes to provide users validation capabilities. However, QUDT provides SHACL shapes, so it would be worth either importing their shapes, or writing the few shapes we need if their transitive closure proves too unwieldy.

I will make a few adjustments to the proposal text. Also, @cyberinvestigationexpress , Competency 2 accidentally duplicated its description from Competency 1. Could you please revise the initial issue post to include the text you meant?

[plbt5]

IMHO, for something to be modeled by use of SOSA I think it should clearly match the Sensor-Observation-Sampling-Actuator pattern. The same holds for SSN, since that has SOSA in its core. This is different for QUDT that is designed to support interoperability and transformations between values that are expressed in some unit of quantity, implying that any value (a point in a value scale) that expresses a magnitude of a quantity in a given system of units, can be expressed by a QUDT statement.

Having said that, some remarks about the CQs:

• CQ 1.1: I think the competency asks for the fact that a phone has been unlocked by the user at a certain time. The type of competency therefore is about an Event as opposed to a Measurement. I discourage the use of SOSA/SSN to express this competency, and suggest to introduce a Perdurant to represent events, and specialise into the various events that are required, here UnlockDevice.
• CQ 3.1: Establishing a crypto wallet value is not a measurement in the accepted interpretation of the term, particularly because its measurement principle is not one of a physical, chemical, or biological nature, but a simple lookup only. Expressing it as a measurement should be discouraged, whereas representing its value in terms of QUDT is advised.