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.
Figure 1 presents an overview of the classes and the properties included in the SAREF4WEAR extension.
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.
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.
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.
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:
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 (geosp: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 geosp:Feature).
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.
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).
This documentation page was generated automatically using SPARQL-Generate, developed by Maxime Lefrançois. The SAREF public portal, the SAREF sources with continuous integration and deployment, the SAREF Pipeline software, and ETSI Technical Specification TS 103 673 v1.1.1 "SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions", have been developed in the context of the ETSI STF 578, which followed the ETSI STF 556.