changes acording to remarks from TP62

TS-0041-oneM2M-SensorThings_interworking.md

@@ -68,14 +68,10 @@ References are either specific (identified by date of publication and/or edition
 
 
 ## 2.1 Normative references
-<mark>Clause 2.1 only shall contain normative (essential) references which are cited in the document itself. These references have to be publicly available and in English.</mark>
 
-The following referenced documents are necessary, partially or totally, for the application of the present document. Their use in the context of this TS is specified by the normative statements that are referring back to this clause.
 
 
-- Use the **EX** style, enclose the number in square brackets and separate it from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.4: "Sequence numbering") (see example).
-
-`EXAMPLE:`  
+ 
 - <a name="_ref_1">[1]</a>    OGC SensorThings API "Part 1: Sensing Version 1.1" (http://www.opengis.net/doc/is/sensorthings/1.1)
 
 ## 2.2 Informative references
@@ -88,7 +84,7 @@ The following referenced documents are not necessary for the application of the
 - Use the **EX** style, add the letter "i" (for informative) before the number (which shall be in square brackets) and separate this from the title with a tab (you may use sequence fields for automatically numbering references).
 
 - <a href="#_ref_i.1">[i.1]</a>    oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf)
-- <a href="#_ref_i.2">[i.2]</a>    OGC SensorThings API "Part 2 – Tasking Core" ( http://www.opengis.net/doc/IS/sensorthings-part2-TaskingCore/1.0)    
+    
 
 
 # 3 Definition of terms, symbols and abbreviations
@@ -153,9 +149,9 @@ The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in
 
 
 # 5 Introduction to OGC SensorThings API
-&lt;Text>
 
-The SensorThings API (STA) is a standard of the Open Geospatial Consortium (OGC). It provides a framework for communication and exchanging data between sensors and applications. The standard is devided in two parts. SensorThings API Part 1 is dedicated to sensing and was published in 2016 and updated in 2021 <a href="#_ref_1">[1]</a>. Part 2 deals with tasking and was published in 2019 <a href="#_ref_i.2">[i.2]</a>.   
+
+The SensorThings API (STA) is a standard of the Open Geospatial Consortium (OGC). It provides a framework for communication and exchanging data between sensors and applications. The standard is devided in two parts. SensorThings API Part 1 is dedicated to sensing and was published in 2016 and updated in 2021 <a href="#_ref_1">[1]</a>.    
 A STA-based architecture works in client/server mode. A sensor device pushes data to the SensorThings Server via HTTP. A SensorThings Server may also support MQTT protocol to support publish and subscribe capabilities. An interested application can subscribe to the MQTT-Broker, in order to get notified about new sensor events.
 
 <figure>
@@ -163,11 +159,11 @@ A STA-based architecture works in client/server mode. A sensor device pushes dat
   <figcaption>Figure 5-1 STA message flow</figcaption>
 </figure>
 
-The data in the SensorThings server are organized as according to  “Sensing Entities” (see Figure 5.0-1: “Sensing Entities” data model).
+The data in the SensorThings server are organized as according to  **Sensing Entities** (see Figure 5.0-1: Sensing Entities data model <a href="#_ref_1">[1]</a>).
 
 <figure>
   <img src="media/data_model.jpg" alt="data_model">
-  <figcaption>Figure 5-1 STA Sensing Entities Data Model</figcaption>
+  <figcaption>Figure 5-1 STA Sensing Entities Data Model <a href="#_ref_1">[1]</a></figcaption>
 </figure>
 
 In the Sensing Entities Data Model events or sensor data are called "observations". Before a sensor is able to push an observation to the server it needs at least a 'Thing' and a 'Datastream' entity. This has to be created beforehand. One 'Thing' might have different 'Sensors', one 'Location' or many 'HistoricalLocations'.