added documentation taken from TS 103 410-8

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source abstract.html or abstract.md shall contain a short description of the SAREF project version ontology. It shall not include diagrams.-->

<p>The objective of SAREF4EHAW is to extend <a href="https://saref.etsi.org/core/">SAREF ontology</a> for the eHealth/Ageing-well (EHAW) vertical. </p>

 No newline at end of file

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source acknowledgement.html or acknowledgement.md shall contain a list of acknowledgements. It shall not include diagrams.-->

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source contributors.html or contributors.md shall describe the list of any contributor. The Steering Board and project leader are responsible for approving the list of contributors. The set of contributors in the ontology document shall correspond to the list of contributors in this document source.-->

<ul>

  <li><a href="https://www.linkedin.com/in/lina-nachabe-2b292457/">Lina Nachabe</a> (<a href="http://www.mines-telecom.fr/en/">Institut Mines-Télécom - Télécom SudParis</a>)</li>

  <li><a href="https://research.utwente.nl/en/persons/jo%C3%A3o-luiz-moreira">João Luiz Moreira</a> (<a href="https://utwente.nl/">University of Twente</a>)</li>

  <li><a href="https://pdi.fbk.eu/people/profile/dragoni">Mauro Dragoni</a> (<a href="http://www.fbk.eu/">Fondazione Bruno Kessler</a>)</li>

  <li><a href="http://www.maxime-lefrancois.info/">Maxime Lefrançois</a> (<a href="http://www.mines-telecom.fr/en/">Institut Mines-Télécom - MINES Saint-Étienne</a>)</li>

</ul>

 No newline at end of file

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source creators.html or creators.md shall describe the list of any creator. The Steering Board and project leader are responsible for approving the list of creators. The set of creators in the ontology document shall correspond to the list of creators in this document source.-->

<ul>

  <li><a href="http://www-public.imtbs-tsp.eu/~girodgen/">Marc C. Girod-Genet</a> (<a href="http://www.mines-telecom.fr/en/">Institut Mines-Télécom - Télécom SudParis</a>)</li>

</ul>

 No newline at end of file

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source description.html or description.md shall contain a description of the SAREF project version ontology and how it is intended to be used. It should include diagrams as defined in clause 9.6.2.-->

<p>SAREF4EHAW extension has been specified and formalised by investigating EHAW domain related resources, as reported in ETSI TR 103 509 <a href="#ref-2">[2]</a>, such as: potential stakeholders, standardization initiatives, alliances/associations, European projects, EC directives, existing ontologies, and data repositories. Therefore, SAREF4EHAW modular ontology shall both:</p>

<ul>

  <li>Allow the implementation of a limited set of typical EHAW related use cases already identified in <a href="#ref-2">[2]</a>, i.e.

    <ul>

      <li>Use case 1 “monitoring and support of healthy lifestyles for citizens”,</li>

      <li>Use case 2 “Early Warning System (EWS) and Cardiovascular Accidents detection”.</li>

    </ul>

  </li>

  <li>Fulfil the EHAW related requirements provided in <a href="#ref-2">[2]</a>, mainly the ontological ones that were mostly taken as input for the ontology specification.</li>

</ul>

<p>SAREF4EHAW mainly reuses the following existing ontologies: SAREF (see <a href="#ref-1">[1]</a>), SmartBAN (see <a href="#ref-3">[3]</a>), SAREF4ENVI (see <a href="#ref-4">[4]</a>), SAREF4WEAR (see <a href="#ref-5">[5]</a>) and SAREF4health ontology <a href="#ref-6">[6]</a> which is a very first try to somehow extend SAREF ontology for the health vertical (it has nothing to do with ETSI SAREF4ABCD naming convention). <a href="#Figure1">Figure 1</a> presents the high level view of the envisioned model of SAREF4EHAW ontology. In <a href="#Figure1">Figure 1</a>, classes directly imported from SAREF ontology are in blue and classes specifically developed for SAREF4EHAW are in grey.</p>

<figure id="Figure1">

  <img alt="The SAREF4EHAW Model" src="diagrams/SAREF4EHAW_Model.jpg" style="max-width:100%">

  <figcaption>Figure 1 - High level view of the envisioned semantic model for SAREF4EHAW ontology</figcaption>

</figure>

<p>Within <a href="#Figure1">Figure 1</a>, as well as within all the figures that are depicted in clause 4 of the present document, the following conventions are used: </p>

<ul>

  <li>Arrows are used to represent properties between classes and to represent some RDF, RDF-S and OWL constructs, more precisely:

    <ul>

      <li>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.</li>

      <li>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.</li>

      <li>Dashed arrows with no identifier are used to represent the rdf:type relation, indicating that the element in the origin of the arrow is an instance of the class in the destination of the arrow.</li>

    </ul>

  </li>

  <li>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,</li>

  <li>Individuals are denoted by rectangles in which the identifier is underlined.</li>

</ul>

<p>SAREF4EHAW is extending SAREF ontology for the EHAW vertical and thus shall logically mainly model the following concepts (i.e. classes within <a href="#Figure1">Figure 1</a>):</p>

<ul>

  <li>EHAW system actors (HealthActor class depicted in <a href="#Figure1">Figure 1</a>) that are mainly responsibility parties (plays the role of the legal entity responsible for a Body Area Network – BAN –), patients/users, caregivers, helpers. A caregiver (Caregiver class depicted in <a href="#Figure1">Figure 1</a>) may have one or multiple patients. A helper (Helper class depicted in <a href="#Figure1">Figure 1</a>) may follow one or multiple users and or patients. As also shown in <a href="#Figure1">Figure 1</a>, users and patients may have habits (e.g. smoking or overeating), impairments (e.g. visual or mobility), and postures (e.g. sitting or running).</li>

  <li>Health devices (HealthDevice class depicted in <a href="#Figure1">Figure 1</a>) that are main components of an eHealth system and are mainly BAN hubs (i.e. Body Area Networks dedicated hubs, BanHub class depicted in <a href="#Figure1">Figure 1</a>), Health-dedicated sensors (HealthSensor class depicted in <a href="#Figure1">Figure 1</a>, an equivalent class to SAREF Sensor one), Health-dedicated  actuators (HealthActuator class depicted in <a href="#Figure1">Figure 1</a>, an equivalent class to SAREF Actuator one) and Health-dedicated wearables (HealthWearable class depicted in <a href="#Figure1">Figure 1</a>, an equivalent class to SAREF4WEAR Wearable one). Those health devices have a given function (Funtion class depicted in <a href="#Figure1">Figure 1</a>) necessary to the accomplishment of the task for which those devices were designed,</li>

  <li>An health device could be attached to one or multiples health actors, for example a caregiver that is using this device for a measurement collection session, a patient whose some vital data are measured by this device. This is modelled through the Contact class as depicted in <a href="#Figure1">Figure 1</a>,</li>

  <li>a sensor has a measurement function (MeasurementFunction class depicted in <a href="#Figure1">Figure 1</a>) and has measurement data (Data class depicted in <a href="#Figure1">Figure 1</a>),</li>

  <li>an actuator is used for an actuation process and does action materialised via the Command class as depicted in <a href="#Figure1">Figure 1</a>,</li>

  <li>Wearables, that are smart electronic devices, are also used for monitoring simple/complex vital parameters of patients/users. Wearables are not developed in the present document since they are already fully specified and formalised in ETSI TS 103 410-9. However, they shall also be modelled as possible health-dedicated devices (i.e. sub-class of HealthDevice, as depicted in <a href="#Figure1">Figure 1</a>),</li>

  <li>BAN (Ban class depicted in <a href="#Figure1">Figure 1</a>) that is mainly used for collecting, aggregating and relaying patient or user vital parameters. It shall therefore logically contain BAN-dedicated hubs, health-dedicated sensors, health-dedicated actuators and health-dedicated wearables, as depicted in <a href="#Figure1">Figure 1</a>,</li>

  <li>Measurement collection session (MeasurementCollectionSession class depicted in <a href="#Figure1">Figure 1</a>) that logically involve some health devices and health actors (at least a caregiver and/or a patient/user) as depicted in <a href="#Figure1">Figure 1</a>,</li>

  <li>Measurement data (Data class depicted in <a href="#Figure1">Figure 1</a>) that logically has measurement. This measurement is measured in a given unit of measure, and is manly of two types: single value (Measurement class depicted in <a href="#Figure1">Figure 1</a>), and time series (TimeSeriesMeasurement class depicted in <a href="#Figure1">Figure 1</a>).</li>

</ul>

<p>For semantic interoperability handling purposes, an ontology based solution, combined with sensing-as-a-service and WoT strategies, is retained for SAREF4EHAW. Therefore, an upper level ontology, at service level, shall also be fully modelled (Service class and sub-classes depicted in <a href="#Figure1">Figure 1</a>).</p>

<p>Finally, SAREF4EHAW is an OWL-DL ontology. For embedded semantic analytics purposes, SAREF4EHAW shall be designed using the modularity principle (see ETSI TR 103 509 <a href="#ref-2">[2]</a>) and can thus be mainly described by the following self-contained knowledge sub-ontologies (or modules): HealthActor, Ban, HealthDevice, Function (measured data related concepts included) and Service. </p>

<!-- + add description of each of the four sub ontologies ?-->

 No newline at end of file