SAREF4WEAR ontology and semantics

Introduction and overview

The present document is a technical specification of SAREF4WEAR, an extension of SAREF [1] for the Wearables domain. Clause 4.1 of the present document shortly introduces a high level view of the envisioned SAREF4WEAR semantic model and modular ontology, with the retained concepts (i.e. classes) and their relations.

SAREF4WEAR has been specified and formalized by investigating related resources in the Wearables domain, as reported in ETSI TR 103 510 [i.1], such as:

• potential stakeholders;
• standardization initiatives;
• alliances/associations;
• European projects;
• EC directives;
• existing ontologies; and
• data repositories.

Therefore, SAREF4WEAR shall both:

• Allow the implementation of a limited set of typical Wearable-related use cases already identified in [i.1], i.e.:
  • Use case 1 "Healthcare".
  • Use case 2 "Open Air Public Events".
  • Use case 3 "Closed Environment Events".
• Fulfil the Wearable-related requirements provided in ETSI TR 103 510 [i.1], mainly the ontological ones that were mostly taken as input for the ontology specification.

SAREF4WEAR is an OWL-DL ontology. For embedded semantic analytics purposes, SAREF4WEAR shall be designed using the modularity principle (see ETSI TR 103 510 [i.1]) and can thus be mainly described by a set of knowledge modules. All these SAREF4WEAR modules are fully detailed in clause 4.2 of the present document.

The prefixes and namespaces used in SAREF4WEAR and in the present document are listed in Table 1.

SAREF4WEAR

General Overview

Figure 1 presents the high level view of the envisioned model of SAREF4WEAR ontology. In Figure 1, classes directly imported from SAREF ontology are in light orange, classes directly imported from other SAREF extension ontologies are in green. While classes developed for SAREF4WEAR are in blue.

Within Figure 1, as well as within all the figures that are depicted in clause 4 of the present document, the following conventions are used:

• Arrows are used to represent properties between classes and to represent some RDF, RDF-S and OWL constructs, more precisely:
  • Plain arrows with white triangles represent the rdfs:subClassOf relation between two classes. The origin of the arrow is the class to be declared as subclass of the class at the destination of the arrow.
  • Dashed arrows between two classes indicate a local restriction in the origin class, i.e. that the object property can be instantiated between the classes in the origin and the destination of the arrow. The identifier of the object property is indicated within the arrow.
• Datatype properties are denoted by rectangles attached to the classes, in an UML-oriented way. Dashed boxes represent local restrictions in the class, i.e. datatype properties that can be applied to the class they are attached to.
• Individuals are denoted by rectangles in which the identifier is underlined.

As already introduced in clause 4.1 of the present document SAREF4WEAR is an OWL-DL ontology and shall be designed using the modularity principle (see ETSI TR 103 510 [i.1]) and can thus be mainly described by the following self-contained knowledge modules:

• Feature of interest. This module describes the relationships between the entities that can be equipped with a Wearable and the wearables themselves.
• WearableDevice. This module defines the concept of WearableDevice and the main types of Wearable devices envisaged for the design of the extension.
• Function. This module describes the functionalities with which Wearable devices should be equipped and that have been considered relevant for the wearables domain.
• Occurrence. This module describes occurrences that are relevant for the wearables domain.
• Property. This module presents those properties that can be associated with a wearable device, a wearer, a crowd of people, or the environment of the wearable.
• Wearable component. This module describes the main components of a wearable that are relevant from the modelling purposes since they can be exploited at both reasoning and query time for inferring and/or gathering information of interest.

Feature of interest

The Feature of Interest module describes the different actors that can be equipped with a Wearable device, as presented in Figure 2. There are different types of actors: living organisms (s4wear:LivingOrganism) and software (s4wear:Software). There is also a wearer class (s4wear:Wearer) to describe those living organisms that wear some wearable.

The s4wear:LivingOrganism concept represents any living being that can be equipped with a Wearable device. The s4wear:Software concept represents a program that can be linked with a s4wear:Wearable especially for acquiring information.

The s4wear:Wearer concept defines any saref:LivingOrganism for which the s4wear:featureIsMeasuredByDevice property subsists, i.e. the s4wear:WearableDevice device transmits information related to the connected saref:LivingOrganism.

The s4wear:User concept refers to a saref:FeatureOfInterest for which the s4wear:interactsWith relationship with a s4wear:WearableDevice individual exists.

WearableDevice

This module defines the different type of wearables identified within the requirements described in the ETSI TR 103 510 [i.1].

SAREF4WEAR defines the s4wear:WearableDevice abstract concept representing a saref:Device having the capability of being wore by a s4wear:Wearer.

As depicted in Figure 3, the s4wear:WearableDevice class subsumes three further concepts with information related to the position of the s4wear:WearableDevice with respect to its s4wear:Wearer:

• s4wear:InBodyWearable describing a s4wear:WearableDevice device positioned inside the body of the s4wear:Wearer;
• s4wear:NearBodyWearable describing a s4wear:WearableDevice device positioned near the body of the s4wear:Wearer;
• s4wear:OnBodyWearable describing a s4wear:WearableDevice device positioned on the body (i.e. direct contact) of the s4wear:Wearer.

The latter is furtherly specified with the s4wear:TextileBasedWearable concept describing s4wear:WearableDevice devices integrated into textile products directly.

The extension also allows to define for a Wearable which are the policies (s4wear:Policy) followed by it by means of the s4wear:followsPolicy property.

Besides, the capabilities of a Wearable under specific conditions (ssn-system:SystemCapability), such as its precision or accuracy, can be represented using the ssn-system:hasSystemCapability property.

Function

This model specifies the functions that are considered relevant for the wearables domain. There are three new concepts that are subsumed by the saref:Function concept and it reuses other functions defined in SAREF, as presented in Figure 4:

• saref:ActuatingFunction defines the possibility of a s4wear:WearableDevice device to actuate over a feature of interest;
• s4wear:CommunicatingFunction is a type of saref:EventFunction that defines the possibility of a s4wear:WearableDevice device to transmit data to another s4wear:WearableDevice device or any other saref:Device able to receive data;
• s4wear:ControllingFunction defines the possibility of a s4wear:WearableDevice device to control another object;
• s4wear:NavigatingFunction defines the possibility of a s4wear:WearableDevice device to provide navigation capabilities;
• saref:SensingFunction defines the possibility of a s4wear:WearableDevice device to acquire data by means of sensors integrated into a s4wear:WearableDevice device.

Occurrence

In some cases, wearables will be able to detect occurrences (s4wear:Occurrence) taking place (s4wear:takesPlaceAt) in a location that is relevant to the wearer (geo:Feature). These occurrences can be related to the device detecting them through the s4wear:isDetectedBy property, as shown in Figure 5.

In the context of a smart city, more specific classes can be used from SAREF4CITY [4], to represent events (s4city:Event, a subclass of s4wear:Occurrence) that take place at (s4city:takesPlaceAtFacility) facilities (s4city:Facility, a subclass of geo:Feature).

Property

SAREF4WEAR includes a classification of the different properties that are relevant to the wearables domain, as shown in Figure 6. These properties are classified into Wearable (s4wear:WearableProperty), wearer (s4wear:WearerProperty), crowd (s4wear:CrowdProperty), and environment (s4wear:EnvironmentProperty) ones.

Furthermore, Wearable properties are further classified into electrical one (s4wear:ElectricalProperty) that refer to the electric information of a Wearable, electrical safety ones (s4wear:ElectricalSafetyProperty) that refer to safety information concerning electrical aspects of wearables, and emission one (s4wear:EmissionProperty) that refer to information about kind of emissions (e.g. noise, temperature, etc.) associated with a Wearable.

The extension defines different individuals for each type of water property; however, this list of individuals does not aim to be exhaustive but to reflect the potential use of the ontology.

The SAREF4WEAR extension requires also to represent those devices that measure a certain feature of interest (and those features of interest that are measured by a device) independently of having measures from which this relationship could be inferred. Because of this, in this extension there are four new properties to relate saref:WearableDevice and saref:FeatureOfInterest: s4wear:featureIsMeasuredByDevice, s4wear:featureIsControlledByDevice, s4wear:measuresFeature, and s4wear:controlsFeature.

Wearable component

This model describes some of the components that could be integrated into a s4wear:WearableDevice device. There are different types of components, as depicted in Figure 7:

• a saref:Actuator component, reused from the SAREF ontology [1];
• a saref:Sensor component, reused from the SAREF ontology [1], and a s4wear:TextileBasedSensor component, subclass of the saref:Sensor one, defining sensors that are installed directly on textile products;
• a s4wear:MemoryStorage component defining storage components that can be directly installed within a s4wear:WearableDevice device.

Object properties

In Table 2, there is the list of the object properties defined into the SAREF4WEAR extension. For each object property, there is a report of the name, the domain, the range, and its definition.

Datatype properties

In Table 3, there is the list of the datatype properties defined into the SAREF4WEAR extension. For each datatype property, there is a report of the name, the domain, the range, and its definition.

Instantiating SAREF4WEAR

This clause shows different examples of how to instantiate the SAREF4WEAR extension of SAREF.

In a healthcare scenario the wearer is represented by a user equipped with Wearable devices in charge of monitoring healthy parameters (e.g. heart rate, body temperature, blood oxygenation, etc.) and to inform the user in real-time about his/her status. This scenario can be instantiated into different situations ranging from the self-management of chronic diseases to the simple lifestyle monitor.

The example presented in Figure 8 depicts a wearer (ex:Patient1) who is equipped with a WearableDevice (ex:AccuMed500) that contains a photodetector (ex:Photodetector1); the sensor measures oxygen saturation (ex:OxygenSaturation) through an observation (ex:OxygenLevel97). A similar example is depicted for a runner wearing a heart rate monitor that observes heart rate.

Another scenario is that of open air public events, which refers to the description of open space public events, such as street festivals, by using the SAREF4WEAR extension. As an example, wearables and sensors are used for measuring the sound level limits, for equipping security staff with the necessary devices for receiving proper information, and for managing the crowd movements around the facility. The management of this challenge can be done by means of a network of WearableDevice devices.

The example presented in Figure 9 illustrates an event (ex:MusicFestival2020) that takes place in a facility (ex:MusicFestival2020). The facility contains different sound sensors (ex:SoundSensor) and multiple customers (s4wear:User) who are located through individual GPS trackers (ex:GPSTracker). The example also presents a member of the staff (ex:Staff1) who interacts with a crowd control WearableDevice (ex:Receiver1) that is able to measure queue sizes (s4wear:QueueSize); such WearableDevice has detected the queue created by customers in the toilets (ex:ToiletsQueue).

The closed environment events scenario differs from the previous one due to the environment in which events take place. Here, sensors are used for controlling access, checking the presence of undesired situations (e.g. blazes), and for alerting attendees about emergency situations. At the same time, stewards and security staff members are equipped with wearables for managing communications and for being informed about undesired events (e.g. brawls). Moreover, children could be equipped with wearables for avoiding their loss in the event facility.

The example presented in Figure 10 illustrates an event (ex:VolleyLeagueFinals) that takes place in a facility (ex:ForumAssago). The facility contains different smoke sensors (ex:SmokeSensor) and multiple customers (s4wear:User) who are located through individual GPS trackers (ex:GPSTracker). The example also presents the head of the staff (ex:StaffHead) who interacts with an audio control Wearable (ex:Controller1) that controls the speakers of the facility (ex:FacilitySpeaker1).

Discussion

In the following, several observations about the SAREF4WEAR ontology and its usage are mentioned.

The hierarchies and individuals defined in the extension should not be considered exhaustive, the ontology currently represents those devices described in different relevant standards and directives. It might be needed to extend the hierarchies and lists of individuals for particular use cases, as well as to specialize some of the defined classes.

A last attention point is related to the possibility that this extension will overlap with existing standards partially related to the wearables domain, in particular:

• The IEEE™ P360 [i.2]. This standard gives overview, terminology and categorization for Wearable Consumer Electronic Devices. It outlines an architecture for a series of standard specifications that define technical requirements and testing methods for different aspects of Wearables, from basic security and suitableness of wear to various functional areas like health, fitness and infotainment, etc.
• The HL7 [i.3]. This standard is more related to the healthcare domain, but it is very common and it contains functional model requirements for electronic as well as personal health records.

The SAREF4WEAR extension requires to be able to represent those devices that measure a certain feature of interest (and those features of interest that are measured by a device) independently of having measures from which this relationship could be inferred.

References

Normative references

• [0] ETSI TS 103 410-9 (V2.1.1): "SmartM2M;; Extension to SAREF; Part 9: Wearables Domain".
• [1] ETSI TS 103 264: "SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping".
• [2] ETSI TS 103 548: "SmartM2M; SAREF reference ontology patterns".
• [3] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions".
• [4] ETSI TS 103 410-4: "SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain".

Informative references

• [i.1] ETSI TR 103 510 (V1.1.1) (2019-10): "SmartM2M; SAREF extension investigation; Requirements for Wearables".
• [i.2] IEEE™ P360.
• [i.3] HL7.
• [i.4] ETSI TR 103 781 (V1.1.1): "SmartM2M; Study for SAREF ontology patterns and usage guidelines".

Acknowledgements