documentation generated from TS

For the purposes of the present document, the following abbreviations apply:

* ETSI: European Telecommunications Standards Institute

* GPS: Global Positioning System

* OWL: Ontology Web Language

* OWL-DL: Ontology Web Language-Description Logics

* RDF: Resource Description Framework

* RDF-S: Resource Description Framework Schema

* SAREF: Smart Applications REFerence ontology

* SAREF4CITY: SAREF extension for the Smart Cities domain

* SAREF4WEAR: SAREF extension for the Wearables domain

 No newline at end of file

<div class="alert-warning">NOTE: The text in this section is extracted from ETSI TS 103 410-9 (V2.1.1) <a href="#[0]">[0]</a>, and therefore falls inside the <a href="https://www.etsi.org/intellectual-property-rights">ETSI IPR Policy</a></div>

[The technical specification ETSI TS 103 410-9](#[0]) is a technical specification of SAREF4WEAR, an extension of SAREF [[1]](#[1]) for the Wearables domain. Clause 4.1 of [the technical specification ETSI TS 103 410-9](#[0]) 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 ontology and semantics

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

## 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;

Therefore, SAREF4WEAR shall both:

* Allow the implementation of a limited set of typical Wearable-related use cases already identified in [[i.1]](#[i.1]), i.e.:

* 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]](#[i.1]), mainly the ontological ones that were mostly taken as input for the ontology specification.

* 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]](#[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 technical specification ETSI TS 103 410-9](#[0]).

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 technical specification ETSI TS 103 410-9](#[0]) are listed in [the Namespace Declarations section](#namespacedeclarations).

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

{{table_1}}

<div class="alert-warning">NOTE: The text in this section is extracted from ETSI TS 103 410-9 (V2.1.1) <a href="#[0]">[0]</a>, and therefore falls inside the <a href="https://www.etsi.org/intellectual-property-rights">ETSI IPR Policy</a></div>

## 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](#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.

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.

<figure>

    <img src="diagrams/health-status-monitor.png" alt="Healthcare example"/>

    <figcaption id="Figure_8">Figure 8: Healthcare example</figcaption>

    <img data-docx-width="17.00cm" src="diagrams/health-status-monitor.png" alt="Healthcare example"/>

    <figcaption>Figure 8: Healthcare example</figcaption>

</figure>

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](#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](#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](#s4wear:QueueSize)); such WearableDevice has detected the queue created by customers in the toilets (ex:ToiletsQueue).

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

<figure>

    <img src="diagrams/openair-event.png" alt="Open air event example"/>

    <figcaption id="Figure_9">Figure 9: Open air event example</figcaption>

    <img data-docx-width="17.00cm" src="diagrams/openair-event.png" alt="Open air event example"/>

    <figcaption>Figure 9: Open air event example</figcaption>

</figure>

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](#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](#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).

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

<figure>

    <img src="diagrams/indoor-event.png" alt="Closed environment event example"/>

    <figcaption id="Figure_10">Figure 10: Closed environment event example</figcaption>

    <img data-docx-width="17.00cm" src="diagrams/indoor-event.png" alt="Closed environment event example"/>

    <figcaption>Figure 10: Closed environment event example</figcaption>

</figure>

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