SP edits for pub: API - Part 1

Author: ogcscotts

api/part1/openapi/examples/collections/collections1.json

@@ -3,7 +3,7 @@
     {
       "id": "all_systems",
       "title": "All Connected Systems",
-      "description": "All systems registered on this server (e.g. platforms, sensors, actuators, processes)",
+      "description": "All systems registered on this server (e.g., platforms, sensors, actuators, processes)",
       "itemType": "feature",
       "featureType": "ssn:System",
       "links": [
@@ -18,7 +18,7 @@
     {
       "id": "all_procedures",
       "title": "All Procedures and System Datasheets",
-      "description": "All procedures (e.g. system datasheets) implemented by systems registered on this server",
+      "description": "All procedures (e.g., system datasheets) implemented by systems registered on this server",
       "itemType": "feature",
       "featureType": "sosa:Procedure",
       "links": [

api/part1/openapi/openapi-connectedsystems-1.yaml

@@ -38,13 +38,13 @@ tags:
       In particular, Collections allow a service provider to group resources logically according to any criteria.
       
       For example, collections can be used to:
-        - Group all `Systems` of the same type (e.g. all UAV platforms, all hydrological sensors, etc.).
-        - Group all `Procedures` of the same type (e.g. all platform types, all CBRNE sensor models, etc.).
-        - Group resources by project (e.g. all `Deployments`, `Systems`, `Datastreams` and `Sampling Features` relevant to a given data acquisition campaign)
+        - Group all `Systems` of the same type (e.g., all UAV platforms, all hydrological sensors, etc.).
+        - Group all `Procedures` of the same type (e.g., all platform types, all CBRNE sensor models, etc.).
+        - Group resources by project (e.g., all `Deployments`, `Systems`, `Datastreams` and `Sampling Features` relevant to a given data acquisition campaign)
 
   - name: Systems
     description: |-
-      Systems are entities that can produce data feeds and/or receive commands (e.g. sensors and sensor networks, platforms, actuators,
+      Systems are entities that can produce data feeds and/or receive commands (e.g., sensors and sensor networks, platforms, actuators,
       processing components, etc.). Many systems can be classified as 'observing systems' that produce observations of one or more
       features of interest.
   - name: Deployments
@@ -53,8 +53,8 @@ tags:
   - name: Procedures
     description: |-
       Procedures provide information about the behavior of a system to accomplish its task(s).
-      Procedures include descriptions of system kinds (e.g. a hardware device's datasheet), as well as methodologies or specific
-      configurations of these systems (e.g. steps followed by an operator to accomplish a sensing or sampling task).
+      Procedures include descriptions of system kinds (e.g., a hardware device's datasheet), as well as methodologies or specific
+      configurations of these systems (e.g., steps followed by an operator to accomplish a sensing or sampling task).
   - name: Sampling Features
     description: |-
       Sampling Features link Systems with ultimate features of interest, describing exactly what part of a larger feature is being
@@ -66,7 +66,7 @@ tags:
       Derived properties are specific to a type of feature, a type of system, or even to a particular organization, project or deployment.
       Property definitions are referenced by feature schemas, system and deployment descriptions, datastream and control stream schemas, etc.
       
-      Depending on the context they are used in, they can represent properties that are asserted (e.g. system characteristic), observed
+      Depending on the context they are used in, they can represent properties that are asserted (e.g., system characteristic), observed
       (observed or observable property) or controlled (controlled or controllable property).
 
 paths:

api/part1/openapi/paths/collectionItems.yaml

@@ -24,7 +24,7 @@ post:
     Add a new resource to the parent collection.
 
     If actual resource descriptions are provided in the body, new resources will be created and added to the parent collection.
-    The new resources will also be available at the corresponding canonical resources endpoint (e.g. `/systems` if the resource is a system).
+    The new resources will also be available at the corresponding canonical resources endpoint (e.g., `/systems` if the resource is a system).
 
     Existing resources can also be added to a collection by providing one or more links to existing resources.
   tags:

api/part1/openapi/paths/subsystems.yaml

@@ -1,7 +1,7 @@
 get:
   summary: List subsystems
   description: |-
-    List or search all `System` resources that are subsystems (i.e. components) of a specific parent system.
+    List or search all `System` resources that are subsystems (i.e., components) of a specific parent system.
 
     Note that individual members can also be retrieved by ID directly at the canonical `System` resources endpoint.
   tags:

api/part1/openapi/paths/systems.yaml

@@ -3,7 +3,7 @@ get:
   description: |-
     List or search all `System` resources available from this server endpoint.
 
-    By default, only top level systems are included (i.e. subsystems are ommitted) unless the `parent` query parameter is set.
+    By default, only top level systems are included (i.e., subsystems are ommitted) unless the `parent` query parameter is set.
 
   tags:
     - Systems
@@ -39,7 +39,7 @@ get:
 post:
   summary: Create a new system
   description: |-
-    Add a new top-level `System` resource (i.e. the system will have no parent).
+    Add a new top-level `System` resource (i.e., the system will have no parent).
   tags:
     - Systems
   requestBody:

api/part1/openapi/schemas/geojson/deployedSystem.json

@@ -12,7 +12,7 @@
               "$ref": "../common/commonDefs.json#/$defs/Link"
             },
             "procedure@link": {
-              "description": "Link to the procedure used by the system, or to operate the system, during the deployment (e.g. mission plan for an autonomous system, methodology for human operator).",
+              "description": "Link to the procedure used by the system, or to operate the system, during the deployment (e.g., mission plan for an autonomous system, methodology for human operator).",
               "$ref": "../common/commonDefs.json#/$defs/Link"
             }
           }

api/part1/openapi/schemas/geojson/system.json

@@ -27,7 +27,7 @@
               "$ref": "../common/commonDefs.json#/$defs/TimePeriod"
             },
             "systemKind@link": {
-              "description": "Link to the system kind description (i.e. its nature or specifications).",
+              "description": "Link to the system kind description (i.e., its nature or specifications).",
               "$ref": "../common/commonDefs.json#/$defs/Link"
             }
           }

api/part1/openapi/schemas/sensorml/deployedSystem.json

@@ -5,7 +5,7 @@
     {
       "properties": {
         "id": {
-          "description": "Local ID of the deployed system resource (e.g. locally unique on a server)",
+          "description": "Local ID of the deployed system resource (e.g., locally unique on a server)",
           "type": "string",
           "minLength": 1,
           "readOnly": true

api/part1/standard/23-001r0.adoc

@@ -2,12 +2,12 @@
 :doctype: standard
 :encoding: utf-8
 :lang: en
-:status: draft
+:status: approved
 :committee: technical
 :external-id: http://www.opengis.net/doc/DIS/ogcapi-connectedsystems-1/1.0
-:docnumber: 23-001r0
-:received-date: yyyy-mm-dd
-:issued-date: yyyy-mm-dd
+:docnumber: 23-001
+:received-date: 2025-03-19
+:issued-date: 2025-06-02
 :published-date: yyyy-mm-dd
 :fullname: Alex Robin
 :docsubtype: implementation

api/part1/standard/requirements/subsystem/req_subcollection_time.adoc

@@ -3,7 +3,7 @@
 [%metadata]
 identifier:: /rec/subsystem/collection-datetime
 
-part:: When the `datetime` parameter is omitted, the server SHOULD also include all subsystems that are currently deployed on the parent system (i.e. the association is made via a `Deployment` resource that is currently valid).
+part:: When the `datetime` parameter is omitted, the server SHOULD also include all subsystems that are currently deployed on the parent system (i.e., the association is made via a `Deployment` resource that is currently valid).
 
 part:: When the `datetime` parameter is set to a time instant, the server SHOULD also include all subsystems that were deployed on the parent system at the specified time. This condition is true when the association is made via a `Deployment` resource whose valid time period contains the specified time instant.