Update Overview, Sensing Core and Actuation

23-019.adoc

@@ -12,9 +12,11 @@
 :published-date: 2029-03-30
 :fullname: Hylke van der Schaaf
 :fullname_2: Steve Liang
+:fullname_3: Kathi Schleidt
+:fullname_4: Humaid Kidwai
 :docsubtype: implementation
 :keywords: ogcdoc, OGC document, API, OData, openapi, html, MQTT
-:submitting-organizations: Fraunhofer-Gesellschaft, Germany; University of Calgary, Canada; SensorUp Inc., Canada; Keys, USA; DataCove e.U., Austria
+:submitting-organizations: Fraunhofer-Gesellschaft, Germany; University of Calgary, Canada; DataCove e.U., Austria
 :mn-document-class: ogc
 :mn-output-extensions: xml,html,doc,pdf
 :local-cache-only:
@@ -44,25 +46,27 @@ include::sections/clause_05_conventions.adoc[]
 
 include::sections/clause_06_overview.adoc[]
 
-include::sections/clause_07a_meta_model.adoc[]
+include::sections/clause_07a_sensing_core_entities.adoc[]
 
-include::sections/clause_07b_sensing_entities.adoc[]
+include::sections/clause_07b_sensing_OM_extension.adoc[]
 
 include::sections/clause_07c_sampling_entities.adoc[]
 
 include::sections/clause_07d_actuation_entities.adoc[]
 
-include::sections/clause_08a_abstract_api_overview.adoc[]
+include::sections/clause_08a_meta_model.adoc[]
 
-include::sections/clause_08b_rest_api_read.adoc[]
+include::sections/clause_08b_abstract_api_overview.adoc[]
 
-include::sections/clause_08c_rest_api_create_update_delete.adoc[]
+include::sections/clause_08c_rest_api_read.adoc[]
 
-include::sections/clause_08d_rest_api_batch_requests.adoc[]
+include::sections/clause_08d_rest_api_create_update_delete.adoc[]
 
-include::sections/clause_08e_rest_api_data_array.adoc[]
+include::sections/clause_08e_rest_api_batch_requests.adoc[]
 
-include::sections/clause_08f_pubsub_api.adoc[]
+include::sections/clause_08g_pubsub_api.adoc[]
+
+include::sections/clause_08f_rest_api_data_array.adoc[]
 
 include::sections/clause_09a_bindings_http.adoc[]
 

sections/clause_06_overview.adoc

@@ -50,14 +50,16 @@ For the Things whose location changed, the HistoricalLocations entities offer th
 A Thing also can have multiple Datastreams.
 A Datastream is a collection of Observations grouped by the same ObservedProperty, Sensor and optionally by Feature and ObservingProcedure.
 An Observation is an event performed by a Sensor that produces a result whose value is an estimate of an ObservedProperty of any given Feature which may be a proximate or ultimate FeatureofInterest.
-Details of each above described entity are provided in <<sensing-entities1>>.
+Details of each above described entity are provided in <<sensing-core>>.
 
 The Sampling part is a new addition to the SensorThings API.
 As is often the case, an Observation may not be a true representation of the intended Feature's Property that an Observer may be trying to Observe.
 Sampling is a common strategy to understand the characteristics of an otherwise difficult-to-measure Property of any feature-of-interest.
-In order to generate Samplings, a Sampler, that may be any physical device or even a human being part of a survey campaign, must carefully select a SamplingProcedure.
-Samplings may be generated by a sequence of SamplingProcedures (and vice-versa), however a Sampler must employ a unique SamplingProcedure to maintain unique Sampling-Sampler-SamplingProcedure relationships.
-In scenarios where a Feature is not directly available for Sampling, a PreparationProcedure composed of multiple PreparationSteps may optionally be used to generate a PreparedFeature.
+In order to generate Samplings, a Sampler, that may be any physical device (or even a human being part of a survey campaign), must carefully select a SamplingProcedure.
+A Sampling may be generated by a SamplingProcedure. 
+This SamplingProcedure can be used by multiple Samplers and conversely, a Sampler may implement multiple SamplingProcedures. 
+However, any Sampling that is generated by a Sampler is always associated with a unique SamplingProcedure.
+In scenarios where a Feature is not directly available for Sampling, a PreparationProcedure composed of multiple PreparationSteps may optionally be used to generate a PreparedSample (Feature entity).
 The entities are explained in detail in <<sampling-entities>>.
 
 The Tasking part provides a standard way for parameterizing - also called tasking - of taskable IoT devices, such as individual sensors and actuators, composite consumer / commercial / industrial / smart cities in-situ platforms, mobile and wearable devices, or even unmanned systems platforms such as drones, satellites, connected and autonomous vehicles, etc.
@@ -67,7 +69,7 @@ A TaskingCapability characterizes an Actuator's (or in some cases, a Thing's) ab
 The Tasking Data Model thus mirrors the Sensing Data Model.
 Each of these entities are elaborated further in <<tasking-entities>>.
 
-The <<sensing-entities-om-extn>> and <<relations-extension>> are optional extensions to the data model that may be used for extended data modelling requirements.
+The <<sensing-OM-extension>> and <<relations-extension>> are optional extensions to the data model that may be used for extended data modelling requirements.
 
 [[observations-measurements]]
 === SensorThings API and Relation to ISO/OGC Observations, Measurements and Samples
@@ -116,13 +118,15 @@ SensorThings API uses the term of Sensor to describe the Observer that is used i
 [[revision-differences]]
 === SensorThings API 2.0 changes from 1.1
 [#sta-changes,reftext='{table-caption} {counter:table-num}']
-.Changes in the SensorThings API 2.0 data model compared to v1.x 
+.Changes in the SensorThings API 2.0 data model compared to v1.1
 [width="100%",cols="5,20a",options="header"]
 |====
 | *Entity* | *Changes* 
 | Sensor     | description attribute is now optional and not mandatory
 | Thing      | description attribute is now optional and not mandatory
-| Location   | description attribute is now optional and not mandatory
+| Location   | 
+- description attribute is now optional and not mandatory
+- For a Thing having multiple Locations, these Locations MAY be in same encodingTypes OR the encodingTypes MAY be be in different spaces (e.g., one encodingType in Geometrical space and one encodingType in Topological space).
 | Datastream | 
 
 - description attribute is now optional and not mandatory 
@@ -144,10 +148,8 @@ SensorThings API uses the term of Sensor to describe the Observer that is used i
 
 === Relation to OASIS-OData
 
-The OGC SensorThings API v2 interface is not an OData interface.
+The OGC SensorThings API v2 interface is not an OData interface and does not claim to be an OData service. 
 It specifies a subset of the OData interface, and extends it at the same time.
-
-An SensorThings API Server implementation can implement the full OData specification.
-An OData client can access a SensorThings API service.
+An SensorThings API Server implementation can implement the full OData specification. An OData client can access a SensorThings API service.
 
 EDITOR: Check if this is true

sections/clause_07b_sensing_entities.adoc → sections/clause_07a_sensing_core_entities.adoc

@@ -1,7 +1,5 @@
-[[sensing-entities]]
-=== Sensing Entities
-
-
+[[sensing-core]]
+== The SensorThings API Sensing Core Entities
 All data model requirements classes are grouped in the following requirements class:
 
 
@@ -17,15 +15,13 @@ requirement:: {identifier}/req-class/datamodel/sensing/thing
 requirement:: {identifier}/req-class/datamodel/sensing/location
 requirement:: {identifier}/req-class/datamodel/sensing/historical-location
 requirement:: {identifier}/req-class/datamodel/sensing/datastream
-requirement:: {identifier}/req-class/datamodel/sensing/deployment
-requirement:: {identifier}/req-class/datamodel/sensing/location
-requirement:: {identifier}/req-class/datamodel/sensing/historical-location
-requirement:: {identifier}/req-class/datamodel/sensing/datastream
-requirement:: {identifier}/req-class/datamodel/sensing/deployment
 requirement:: {identifier}/req-class/datamodel/sensing/sensor
+requirement:: {identifier}/req-class/datamodel/sensing/observed-property
+requirement:: {identifier}/req-class/datamodel/sensing/observation
+requirement:: {identifier}/req-class/datamodel/sensing/feature  
 ====
 
-[[sensing-entities2]]
+[[sensing-entities]]
 === Sensing Entities
 
 The OGC SensorThings API v2.0 depicts the Core Sensing entities in Figure {counter:figure-num}
@@ -36,11 +32,10 @@ image::images/GRP0001.png[Sensing Core, align="center"]
 In this section, we define each entity depicted in <<img-sta-core>> and its relationships with other entities.
 Additionally, we also provide examples to model the entities in different contexts.
 
-==== Requirement Class: Thing
+[[thing]]
+==== Thing
 
 [requirements_class]
-.thing
-
 ====
 [%metadata]
 identifier:: {identifier}/req-class/datamodel/sensing/thing
@@ -130,8 +125,6 @@ A Thing SHOULD have only one Location.
 
 However, in some complex use cases, a Thing MAY have more than one Location representations.
 In such case, the Thing MAY have more than one Locations.
-These Locations SHALL have different encodingTypes and the encodingTypes SHOULD be in different spaces (e.g., one encodingType in Geometrical space and one encodingType in Topological space).
-
 | `HistoricalLocation`        | HistoricalLocations  | One mandatory to many optional
 | A Thing has zero-to-many HistoricalLocations.
 A HistoricalLocation has one-and-only-one Thing.
@@ -893,7 +886,7 @@ Each Feature entity SHALL have the mandatory properties and MAY have the optiona
 [%metadata]
 identifier:: {identifier}/req/datamodel/sensing/feature/relations
 
-Each Thing entity SHALL have the direct relation between a Thing entity and other entity types listed in Table XX.
+Each Feature entity SHALL have the direct relation between a Feature entity and other entity types listed in Table {counter:table-num}.
 ====
 
 

sections/clause_07c_sensing_OM_extension.adoc → sections/clause_07b_sensing_OM_extension.adoc

@@ -1,5 +1,3 @@
-:sectnums: |,all|
-:sectanchors:
 [[sensing-OM-extension]]
 === Sensing Extension (Observations & Measurements)