Applied Carl Reed Changes and Corrections

See issue #123

21-049/21-049.adoc

@@ -1,4 +1,4 @@
-= OGC (Points of Interest)
+= OGC (Points of Interest) Conceptual Model Standard
 :doctype: standard
 :encoding: utf-8
 :lang: en
@@ -7,12 +7,13 @@
 :draft: 0.1.1
 :external-id: http://www.opengis.net/doc/is/poi/1.0
 :docnumber: 21-049
-:received-date: 2024-02-15
-:issued-date: 2029-03-30
-:published-date: 2024-02-15
+:received-date: 2024-03-04
+:issued-date: 2024-03-04
+:published-date: 2024-03-04
 :fullname: Charles Heazel
-:fullname_2: Matthew Brian 
-:fullname_3: John Purss
+:fullname_2: Matthew Purss
+:fullname_3: Howard Trickey
+:fullname_4: Christine Perey
 :docsubtype: conceptual
 :keywords: ogcdoc, OGC document, Point of Interest, POI, Feature 
 :submitting-organizations:  Digital Flanders; Google; HeazelTech; Pangaea Innovations; PEREY Research & Consulting; US Army Geospatial Center

21-049/abstract_tests/Core/ATS_Core_GeneralFeatureModel.adoc

@@ -20,7 +20,7 @@ part:: Validate that the Implementation Specification includes an Abstract Test
 
 part:: Validate that the Abstract Test Suite tests for conformance with the General Feature Model defined in <<ISO19109,ISO 19109>>.
 
-NOTE:: If the Implementaion Specification is based on a Standard known to be conformant with ISO 19109 (ex: GML), then conformance with that Standard is sufficient to show conformance with ISO 19109.
+NOTE:: If the Implementation Specification is based on a Standard known to be conformant with ISO 19109 (ex: GML), then conformance with that Standard is sufficient to show conformance with ISO 19109.
 
 ====
 

21-049/abstract_tests/Core/ATS_Core_Geometry.adoc

@@ -20,7 +20,7 @@ part:: Validate that the Implementation Specification includes an Abstract Test
 
 part:: Validate that all geometries used in the Implementation Specification conform with the geometry model defined in <<ISO19107,ISO 19107>>.
 
-NOTE:: If the Implementaion Specification is based on a Standard known to be conformant with ISO 19107 (ex: GML), then conformance with that Standard is sufficient to show conformance with ISO 19107.
+NOTE:: If the Implementation Specification is based on a Standard known to be conformant with ISO 19107 (ex: GML), then conformance with that Standard is sufficient to show conformance with ISO 19107.
 
 part:: Validate that the Abstract Test Suite tests each POI Feature for the presence of a `SpatialAttributeType` property of type GM_Point, GM_LineString, or GM_Polygon.
 

21-049/abstract_tests/Core/ATS_Core_POI_Payload.adoc

@@ -36,7 +36,7 @@ test-method-type:: Manual Inspection
 
 description:: Validate the cardinality and target class of the `usesSchema` aggregation.
 
-part:: Validate that at least one `usesSchema` aggregation is allowed in an POI_Payload class.
+part:: Validate that at least one `usesSchema` aggregation is allowed in a POI_Payload class.
 
 part:: Validate that the target of the `usesSchema` aggregation is a valid schema for the implementing technology.
 ====
@@ -56,7 +56,7 @@ test-method-type:: Manual Inspection
 
 description:: Validate the cardinality and target class of the `hasDefinition` aggregation.
 
-part:: Validate that no more than one `hasDefinition` aggregation is allowed in an POI_Payload class.
+part:: Validate that no more than one `hasDefinition` aggregation is allowed in a POI_Payload class.
 
 part:: Validate that the target of the `hasDefinition` aggregation is a valid ontology for the implementing technology.
 ====
@@ -76,7 +76,7 @@ test-method-type:: Manual Inspection
 
 description:: Validate the cardinality and target class of the `hasFeatureOfInterest` aggregation.
 
-part:: Validate that zero or more `hasFeatureOfIntestest` aggregations are allowed in an POI_Payload class.
+part:: Validate that zero or more `hasFeatureOfIntestest` aggregations are allowed in a POI_Payload class.
 
 part:: Validate that the target of the `hasFeatureOfInterest` aggregation is a valid implementation of the Feature class from <<ISO19109,ISO 19109:2015>>.
 ====

21-049/sections/annex-b_ISO_model.adoc

@@ -2,9 +2,9 @@
 [[iso_data_dictionary_section]]
 == ISO Data Dictionary
 
-ISO Technical Committee 211 maintains a harmonized UML model which covers many of their standards. All of the TC211 Standards which are relevant to the POI Standard are included. Therefore the full UML model for POI consists of the classes defined in the POI UML model as well as those which referenced from the TC211 Hamonized UML model.
+ISO Technical Committee 211 maintains a harmonized UML model which covers many of their standards. All the TC211 Standards which are relevant to the POI Standard are included. Therefore the full UML model for POI consists of the classes defined in the POI UML model as well as those which referenced from the TC211 Harmonized UML model.
 
-The Data Dictionary tables in this section were software generated from the TC211 Hamonized UML model. As such, this section provides a normative representation of the TC211 classes which are leveraged by the POI Conceptual Model.
+The Data Dictionary tables in this section were software generated from the TC211 Harmonized UML model. As such, this section provides a normative representation of the TC211 classes which are leveraged by the POI Conceptual Model.
 
 Note that some of the properties in the ISO model are not populated. Since the model is normative, the missing information cannot be included in this document until it is first included in the ISO model by TC211.
 
@@ -41,7 +41,7 @@ In an implementation this abstract class shall be substituted by a concrete clas
 !===
 !{nbsp}{nbsp}{nbsp}{nbsp}Definition: ! feature: abstraction of real world phenomena +
 NOTE: A feature may occur as a type or an instance. Feature type or feature instance should be used when only one is meant. +
-This class describes how a feature class shall be constructed in an Application Schema. In accordance with the conformance clause of the standard, instances of this class are instanciated as feature classes in an Application Schema
+This class describes how a feature class shall be constructed in an Application Schema. In accordance with the conformance clause of the standard, instances of this class are instantiated as feature classes in an Application Schema
 !{nbsp}{nbsp}{nbsp}{nbsp}Subclass Of: ! IdentifiedType 
 !{nbsp}{nbsp}{nbsp}{nbsp}StereoType: !  «Metaclass»
 !{nbsp}{nbsp}{nbsp}{nbsp}Constraint: ! name is mandatory (Invariant):     
@@ -142,7 +142,7 @@ NOTE In most cases, the state of a GM_Point is fully determined by its position
 |*GM_Polygon* 
 |[cols="1,4",frame=none,grid=none]
 !===
-!{nbsp}{nbsp}{nbsp}{nbsp}Definition: ! A GM_Polygon (Figure 21) is a surface patch that is defined by a set of boundary curves and an underlying surface to which these curves adhere. The default is that the curves are coplanar and the polygon uses planar interpolation in its interior.  
+!{nbsp}{nbsp}{nbsp}{nbsp}Definition: ! A GM_Polygon (Figure 21) is a surface patch that is defined by a set of boundary curves and an underlying surface to which these curves adhere. The default is that the curves are coplanar, and the polygon uses planar interpolation in its interior.  
 !{nbsp}{nbsp}{nbsp}{nbsp}Subclass Of: ! GM_Primitive 
 !{nbsp}{nbsp}{nbsp}{nbsp}StereoType: !  «type»
 !===
@@ -318,7 +318,7 @@ The following classes are defined in <<ISO19115,(ISO 19115-1 Edition 1)>>
 
 !{set:cellbgcolor:#FFFFFF} graphic   !MD_BrowseGraphic  [0..*] !graphic /symbol indicating the constraint 
 
-!{set:cellbgcolor:#FFFFFF} reference   !CI_Citation  [0..*] !citation/URL for the limitation or constraint, eg. copyright statement, license agreement, etc
+!{set:cellbgcolor:#FFFFFF} reference   !CI_Citation  [0..*] !citation/URL for the limitation or constraint, e.g. copyright statement, license agreement, etc
 
 !{set:cellbgcolor:#FFFFFF} releasability   !<<MD_Releasability-section,MD_Releasability>>  [0..1] !information concerning the parties to whom the resource can or cannot be released
 
@@ -424,7 +424,7 @@ The following classes are defined in <<ISO19115,(ISO 19115-1 Edition 1)>>
 
 !{set:cellbgcolor:#FFFFFF} conceptIdentifier   !URI  [0..1] !URI of concept in ontology specified by the ontology attribute; this concept is labeled by the className: CharacterString.
 
-!{set:cellbgcolor:#FFFFFF} ontology   !CI_Citation [1..1]  !a reference that binds the keyword class to a formal conceptualization of a knowledge domain for use in semantic processingNOTE: Keywords in the associated MD_Keywords keyword list must be within the scope of this ontology
+!{set:cellbgcolor:#FFFFFF} ontology   !CI_Citation [1..1]  !a reference that binds the keyword class to a formal conceptualization of a knowledge domain for use in semantic processing. NOTE: Keywords in the associated MD_Keywords keyword list must be within the scope of this ontology
 !===
 |=== 
 

21-049/sections/clause_0_front_material.adoc

@@ -24,24 +24,24 @@ Attention is drawn to the possibility that some of the elements of this document
 
 [abstract]
 == Abstract
-The OGC Points of Interest (POI) conceptual model is an open data model for representing information about POI. 
-It is defined through a Unified Modeling Language (UML) object model. 
+The OGC Points of Interest (POI) Conceptual Model is an open data model for representing information about POI. 
+The model is defined using a Unified Modeling Language (UML) object model. 
 This UML model extends the ISO Technical Committee 211 (TC211) conceptual model standards for spatial and temporal data. 
-Building on the ISO foundation assures that the features described in the POI Models share the same spatial-temporal universe as described by related standards (e.g., CityGML).
+Building on the ISO foundation assures that the features described in the POI Model share the same spatiotemporal universe as described by related standards (e.g., CityGML).
 
-The aim of developing the OGC POI conceptual model is to reach a common definition of the basic entities, attributes, and relations of “points of interest.” 
-In the broadest terms, a point of interest is a location about which information of general interest is available. 
+The goal for developing the OGC POI Conceptual Model is to reach a common definition of the basic entities, attributes, and relations of “points of interest.” 
+In the broadest terms, a POI is a location about which information of general interest is available. 
 A POI can be as simple as a set of coordinates and an identifier, or more complex such as a three-dimensional model of a building with names in various languages, information about open and closed hours, and a civic address.
 
 [security-considerations-section]
 == Security Considerations
 
-The POI Conceptual model defines a POI as a type of Feature. 
+The POI Conceptual Model defines a POI as a type of Feature. 
 By building on the same Feature Model as other OGC Feature models, POI implementations inherit the security controls and vulnerabilities of their associated Feature Dataset.
 They are a Feature like any other. +
 
-This document is a Standard for a Conceptual Model. 
-Implementations of this Standad (Implementation Specifications) are free to add additional details and content necessary to enable implementation-specific security controls. 
-In the event that anything in this Standard prevents implementation of needed controls, implementors are requested to notify the POI Standards Working Group and help devise a solution.
+This document defines a Conceptual Model Standard. 
+Implementations of this Standard (Implementation Specification) are free to add additional details and content necessary to enable implementation-specific security controls. 
+In the event that anything in this Standard prevents implementation of needed controls, implementors are requested to notify the POI Standards Working Group (SWG) and help devise a solution.
 
 

21-049/sections/clause_1_scope.adoc

@@ -1,12 +1,12 @@
 == Scope
 
-This document describes a conceptual model for representing information about points of interest (POI).
+The OGC Points of Interest Conceptual Model Standard (this document) describes a conceptual model for representing information about points of interest (POI).
 
 In the broadest terms, a "point of interest" is a location about which information of general interest is available. A POI can be as simple as a set of coordinates and an identifier, or more complex such as a three-dimensional model of a building with names in various languages, information about open and closed hours, and a civic address.
 
 POI data has many uses including navigation systems, mapping, geocaching, location-based social networking games, and augmented reality browsers.
 
-POI data has traditionally been exchanged in proprietary formats by various transport mechanisms. This specification defines a flexible, lightweight, extensible POI data model. This will enable content publishers to effectively describe and efficiently serve and exchange POI data.
+POI data has traditionally been exchanged in proprietary formats by various transport mechanisms. This document defines a flexible, lightweight, extensible POI data model. This will enable content publishers to effectively describe and efficiently serve and exchange POI data.
 
-To achieve these goals, this document describes a generic data model that may be instantiated in a variety of serializations, including XML, JSON and RDF. The data model is designed to be extended with POI information specific to the geospatial data it represents.
+To achieve these goals, this document describes a generic data model that may be instantiated in a variety of serializations, including XML, JSON, and RDF. The data model is designed to be extended with POI information specific to the geospatial data it represents.
 

21-049/sections/clause_2_conformance.adoc

@@ -1,21 +1,21 @@
 [[conformance-section]]
 == Conformance
 
-This standard defines a <<conceptual-model-definition,Conceptual Model>> which is independent of any encoding or formatting techniques. 
-The <<standardization-target-definition,Standardization Target>> for this standard is technology-specific POI <<implementation-specification-definition,Implementation Specifications>>.
+This Standard defines a <<conceptual-model-definition,Conceptual Model>> which is independent of any encoding or formatting techniques. 
+The <<standardization-target-definition,Standardization Target>> for this Standard is technology-specific POI <<implementation-specification-definition,Implementation Specifications>>.
 
-=== Implementation Specifications
+=== OGC Implementation Specifications
 
 Implementation Specifications define how a Conceptual Model should be implemented using a specific technology. Conformant Implementation Specifications provide evidence that they are an accurate representation of the Conceptual Model. This evidence should include implementations of the abstract tests specified in <<abstract-test-suite-section,Annex A>> (normative) of this document. 
 
-Since this standard is agnostic to the implementing technologies, the specific techniques to be used for conformance testing cannot be specified. Implementation Specifications need to provide evidence of conformance which is appropriate for the implementing technologies. This evidence should be provided as an annex to the Implementation Specification document.
+Since this Standard is implementing technology agnostic, the specific techniques to be used for conformance testing cannot be specified. Implementation Specifications need to provide evidence of conformance which is appropriate for the implementing technologies. This evidence should be provided as Annex A to the Implementation Specification document.
 
 === Implementations
 
 POI implementations will typically be a simplified representation of a more complex dataset. Implementors may want to extend the POI model to include properties specific to that dataset. These extensions are accomplished using the POI Payload mechanism described in <<poi_payload-section,POI Payload>>. Since the POI Payload has its own definition of syntax and semantics, conformance with the POI Standard cannot ensure payload conformance. 
 
 === Conformance Classes
 
-This standard identifies one "Core" <<conformance-class-definition,conformance class>>. This conformance class defines the conformance criteria for the requirements defined in one "Core" <<requirements-class-definition,requirements class>>. The tests this conformance class are documented in <<abstract-test-suite-section,Annex A>>. These tests are organized by Requirements Class. So an implementation of the Core conformance class must pass all tests specified in <<abstract-test-suite-section,Annex A>> for the Core Requirements Class.
+This Standard identifies one "Core" <<conformance-class-definition,conformance class>>. This conformance class defines the conformance criteria for the requirements defined in one "Core" <<requirements-class-definition,requirements class>>. The tests this conformance class are documented in <<abstract-test-suite-section,Annex A>>. These tests are organized by Requirements Class. So an implementation of the Core conformance class must pass all tests specified in <<abstract-test-suite-section,Annex A>> for the Core Requirements Class.
 
 The POI Conceptual Model is defined by the POI UML model. This Standard is a representation of that UML model in document form. In the case of a discrepancy between the UML model and this document, the UML model takes precedence.