SAREF4WEAR: an extension of SAREF for Wearables

Introduction

This document presents the implementation of the SAREF extension for the wearables domain (SAREF4WEAR) which based on a limited set of use cases and from available existing data models. This work has been developed in the context of the STF 566 which was established with the goal to create SAREF extensions for the domains of automotive, eHealth and ageing well, wearables, and water.

General overview

Figure 1 presents an overview of the classes and the properties included in the SAREF4WEAR extension.

Measurement

As it can be observed in Figure 2, the modelling of measurements in the SAREF4WEAR ontology mostly relies on the measurement model proposed in SAREF.

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. Because of this, in this extension we have created four new properties to relate saref:Device and saref:FeatureOfInterest: s4wear:featureIsMeasuredByDevice, s4wear:featureIsControlledByDevice, s4wear:measuresFeature, and s4wear:controlsFeature.

Feature of interest

The Feature of Interest module describes the different actors that can be equipped with a Wearable device, as presented in Figure 3. We foresee 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:Wearable 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:Wearable individual exists.

Wearable

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

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

• s4wear:InBodyWearable describing a s4wear:Wearable device positioned inside the body of the s4wear:Wearer;
• s4wear:NearBodyWearable describing a s4wear:Wearable device positioned near the body of the s4wear:Wearer;
• s4wear:OnBodyWearable describing a s4wear:Wearable 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:Wearable 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. We defined three new concepts that are subsumed by the saref:Function concept and we reuse other functions defined in SAREF, as presented in Figure 5:

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

In the context of a smart city, more specific classes can be used from SAREF4CITY, 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 7. 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.

Wearable component

This model describes some of the components that could be integrated into a s4wear:Wearable device. We foresee different types of components, as depicted in Figure 8:

• a saref:Actuator component, reused from the SAREF ontology;
• a saref:Sensor component, reused from the SAREF ontology, 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:Wearable device.

Examples

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 9 depicts a wearer (ex:Patient1) who is equipped with a wearable (ex:AccuMed500) that contains a photodetector (ex:Photodetector1); the sensor measures oxygen saturation (ex:OxygenSaturation) through a measurement (ex:OxygenLevel97). A similar example is depicted for a runner wearing a heart rate monitor that measures 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 wearable devices.

The example presented in Figure 10 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 wearable (ex:Receiver1) that is able to measure queue sizes (s4wear:QueueSize); such wearable 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 11 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).