\ No newline at end of file
diff --git a/documentation/creators.html b/documentation/creators.html
new file mode 100644
index 0000000000000000000000000000000000000000..6047730938d90c439dc87de32cf2d4adb97da082
--- /dev/null
+++ b/documentation/creators.html
@@ -0,0 +1,5 @@
+
+
+
\ No newline at end of file
diff --git a/documentation/description.html b/documentation/description.html
new file mode 100644
index 0000000000000000000000000000000000000000..f6add9dfec59a256a1970fc02b7617d2d66be663
--- /dev/null
+++ b/documentation/description.html
@@ -0,0 +1,54 @@
+
+
+
SAREF4EHAW extension has been specified and formalised by investigating EHAW domain related resources, as reported in ETSI TR 103 509 [2], such as: potential stakeholders, standardization initiatives, alliances/associations, European projects, EC directives, existing ontologies, and data repositories. Therefore, SAREF4EHAW modular ontology shall both:
+
+
+
Allow the implementation of a limited set of typical EHAW related use cases already identified in [2], i.e.
+
+
Use case 1 “monitoring and support of healthy lifestyles for citizens”,
+
Use case 2 “Early Warning System (EWS) and Cardiovascular Accidents detection”.
+
+
+
Fulfil the EHAW related requirements provided in [2], mainly the ontological ones that were mostly taken as input for the ontology specification.
+
+
+
SAREF4EHAW mainly reuses the following existing ontologies: SAREF (see [1]), SmartBAN (see [3]), SAREF4ENVI (see [4]), SAREF4WEAR (see [5]) and SAREF4health ontology [6] 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). Figure 1 presents the high level view of the envisioned model of SAREF4EHAW ontology. In Figure 1, classes directly imported from SAREF ontology are in blue and classes specifically developed for SAREF4EHAW are in grey.
+
+
+
+ Figure 1 - High level view of the envisioned semantic model for SAREF4EHAW ontology
+
+
+
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.
+
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.
+
+
+
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.
+
+
+
SAREF4EHAW is extending SAREF ontology for the EHAW vertical and thus shall logically mainly model the following concepts (i.e. classes within Figure 1):
+
+
EHAW system actors (HealthActor class depicted in Figure 1) 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 Figure 1) may have one or multiple patients. A helper (Helper class depicted in Figure 1) may follow one or multiple users and or patients. As also shown in Figure 1, users and patients may have habits (e.g. smoking or overeating), impairments (e.g. visual or mobility), and postures (e.g. sitting or running).
+
Health devices (HealthDevice class depicted in Figure 1) that are main components of an eHealth system and are mainly BAN hubs (i.e. Body Area Networks dedicated hubs, BanHub class depicted in Figure 1), Health-dedicated sensors (HealthSensor class depicted in Figure 1, an equivalent class to SAREF Sensor one), Health-dedicated actuators (HealthActuator class depicted in Figure 1, an equivalent class to SAREF Actuator one) and Health-dedicated wearables (HealthWearable class depicted in Figure 1, an equivalent class to SAREF4WEAR Wearable one). Those health devices have a given function (Funtion class depicted in Figure 1) necessary to the accomplishment of the task for which those devices were designed,
+
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 Figure 1,
+
a sensor has a measurement function (MeasurementFunction class depicted in Figure 1) and has measurement data (Data class depicted in Figure 1),
+
an actuator is used for an actuation process and does action materialised via the Command class as depicted in Figure 1,
+
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 Figure 1),
+
BAN (Ban class depicted in Figure 1) 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 Figure 1,
+
Measurement collection session (MeasurementCollectionSession class depicted in Figure 1) that logically involve some health devices and health actors (at least a caregiver and/or a patient/user) as depicted in Figure 1,
+
Measurement data (Data class depicted in Figure 1) 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 Figure 1), and time series (TimeSeriesMeasurement class depicted in Figure 1).
+
+
+
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 Figure 1).
+
+
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 [2]) 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.
+
+
+
\ No newline at end of file
diff --git a/diagrams/.gitkeep b/documentation/diagrams/.gitkeep
similarity index 100%
rename from diagrams/.gitkeep
rename to documentation/diagrams/.gitkeep
diff --git a/diagrams/S4EHAW-Ban.jpg b/documentation/diagrams/S4EHAW-Ban.jpg
similarity index 100%
rename from diagrams/S4EHAW-Ban.jpg
rename to documentation/diagrams/S4EHAW-Ban.jpg
diff --git a/diagrams/S4EHAW-Function.jpg b/documentation/diagrams/S4EHAW-Function.jpg
similarity index 100%
rename from diagrams/S4EHAW-Function.jpg
rename to documentation/diagrams/S4EHAW-Function.jpg
diff --git a/diagrams/S4EHAW-HealthActor.jpg b/documentation/diagrams/S4EHAW-HealthActor.jpg
similarity index 100%
rename from diagrams/S4EHAW-HealthActor.jpg
rename to documentation/diagrams/S4EHAW-HealthActor.jpg
diff --git a/diagrams/S4EHAW-HealthDevice.jpg b/documentation/diagrams/S4EHAW-HealthDevice.jpg
similarity index 100%
rename from diagrams/S4EHAW-HealthDevice.jpg
rename to documentation/diagrams/S4EHAW-HealthDevice.jpg
diff --git a/diagrams/S4EHAW-Service.jpg b/documentation/diagrams/S4EHAW-Service.jpg
similarity index 100%
rename from diagrams/S4EHAW-Service.jpg
rename to documentation/diagrams/S4EHAW-Service.jpg
diff --git a/diagrams/SAREF4EHAW_Model.jpg b/documentation/diagrams/SAREF4EHAW_Model.jpg
similarity index 100%
rename from diagrams/SAREF4EHAW_Model.jpg
rename to documentation/diagrams/SAREF4EHAW_Model.jpg
diff --git a/diagrams/SAREF4EHAW_Modular-Ontology_v6.pptx b/documentation/diagrams/SAREF4EHAW_Modular-Ontology_v6.pptx
similarity index 100%
rename from diagrams/SAREF4EHAW_Modular-Ontology_v6.pptx
rename to documentation/diagrams/SAREF4EHAW_Modular-Ontology_v6.pptx
diff --git a/documentation/examples.html b/documentation/examples.html
new file mode 100644
index 0000000000000000000000000000000000000000..7bd459fc69c39cd306b579e54ca28e7923404e79
--- /dev/null
+++ b/documentation/examples.html
@@ -0,0 +1,2 @@
+
+
\ No newline at end of file
diff --git a/documentation/references.html b/documentation/references.html
new file mode 100644
index 0000000000000000000000000000000000000000..08799f3485ddba9b5723eb1f699e3aef4bc5539b
--- /dev/null
+++ b/documentation/references.html
@@ -0,0 +1,11 @@
+
+
+
+
+
[1]
ETSI TS 103 264 (V2.1.1) (2017-03): "SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping".
+
[2]
ETSI TS 103 509 (V1.1.1) (2019-09): “SmartM2M; SAREF extension investigation; Requirements for eHealth/Ageing-well”.
+
[3]
ETSI TS 103 378r1: "Smart Body Area Networks (SmartBAN) Unified data representation formats, semantic and open data model".
+
[4]
ETSI TS 103 410-2 V1.1.1 (2017-01): “SmartM2M; Smart Appliances Extension to SAREF; Part 2: Environment Domain”.
+
[5]
ETSI TS 103 510 (V1.1.1) (2019-09): “SmartM2M; SAREF extension investigation; Requirements for Wearables”.
+
[6]
J. L. R. Moreira, L. Ferreira Pires, M. van Sinderen, L. Daniele: "SAREF4health: IoT Standard-Based Ontology-Driven Healthcare Systems". FOIS 2018: 239-252.
+