metanorma fixes

spec/sections/01-preface.adoc

@@ -1,3 +1,4 @@
+[abstract]
 == Abstract 
 
 GeoSPARQL contains a small spatial domain OWL ontology that allow literal representations of geometries to be associated with spatial features and for features to be associated with other features using spatial relations.
@@ -35,13 +36,20 @@ The OGC GeoSPARQL Standard defines:
 
 This document authoritatively defines many of the Standard's elements, including the ontology classes and properties, SPARQL functions, and function and rule vocabulary concepts. Complete descriptions of the Standard's parts and their roles are given in the Introduction in the section <<GeoSPARQL Standard structure>>.
 
+[.preface]
+== Keywords
+
+Open Geospatial Consortium, OGC, spatial, ontology, Knowledge Graph, Semantic Web, Linked Data, RDF, Resource Description Framework, Web Ontology Language, OWL, SPARQL, Simple Features, feature, geometry
+
+[.preface]
 == Clarifications
 
 * The terms <<spatial reference system, Spatial Reference System (SRS)>> and <<coordinate reference system, Coordinate Reference System (CRS)>> are no longer interchangeable. Spatial Reference System is now taken to be a broader category than Coordinate Reference System. These are defined in the <<Terms and definitions>> section.
 * Class definitions were updated to be more self-contained and easier to understand for people without a background in geoinformatics. The definitions are no longer dependent on other standards' definitions, only informed by them.
 * A section was added on <<Recommendation for specification of units of measurement,the specification of units of measurement>>.
 * A section was added on the <<Influence of Coordinate Reference Systems on geometric computations>>.
 
+[.preface]
 == v. Changes to the OGC® Abstract Specification
 The OGC® Abstract Specification does not require changes to accommodate this OGC® standard.
 
@@ -52,29 +60,12 @@ Recipients of this document are requested to submit, with their comments, notifi
 
 
 [.preface]
-
-== Submitting Organizations
-
-The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
-
-* CSIRO
-* Cubewerx Inc
-* Defence Science and Technology Laboratory (DSTL)
-* Geonovum
-* Geoscape Australia
-* Geoscience Australia
-* Mainz University Of Applied Sciences
-* Oracle America
-* OSGeo
-* SURROUND Australia Pty Ltd.
-
-
 == Submitters
 
 All questions regarding this submission should be directed to the editor or the submitters:
 
 [%unnumbered]
-[frame=none, grid=none, cols="1, 3"]
+[%header, cols="1, 3"]
 |===
 |Contact | Company
 | Simon J.D. Cox | CSIRO
@@ -88,3 +79,21 @@ All questions regarding this submission should be directed to the editor or the
 | Nicholas J. Car | SURROUND Australia Pty Ltd.
 |===
 
+[.preface]
+== Submitting Organizations
+
+The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
+
+* CSIRO
+* Cubewerx Inc
+* Defence Science and Technology Laboratory (DSTL)
+* Geonovum
+* Geoscape Australia
+* Geoscience Australia
+* Mainz University Of Applied Sciences
+* Oracle America
+* OSGeo
+* SURROUND Australia Pty Ltd.
+
+
+

spec/sections/02-introduction.adoc

@@ -1,3 +1,4 @@
+:sectnums!:
 == Introduction
 
 The W3C Semantic Web Activity is defining a collection of technologies that enables a “web of data” where information is easily shared and reused across applications. Some key pieces of this technology stack are the RDF (Resource Description Framework) data model <<RDF>>, <<RDFS>>, the OWL Web Ontology Language <<OWL2>> and the SPARQL protocol and RDF query language <<SPARQL>>.
@@ -10,7 +11,7 @@ RDF is, among other things, a data model built on edge-node "graphs." Each link
 * Predicate (verb, property, attribute, relation, member, link, reference)
 * Object (value, end node, non-literal values can be used as a Subject)
 
-Any of the three values in a triple can be represented with a Internationalized Resource Identifier (IRI) <<IETF3987>>, which globally and uniqueliy identifies the resource referenced. IRIs are an extension to Universal Resource Identifiers (URIs) that allow for non-ASCII characters. In addition to functioning as identifiers, IRIs are usually, but not necissarily, resolvable which means a person or machine can "dereference" them (_click on them_ or otherwise action them) and be taken to more information about the resource, perhaps in a web browser. 
+Any of the three values in a triple can be represented with a Internationalized Resource Identifier (IRI) <<IETF3987>>, which globally and uniquely identifies the resource referenced. IRIs are an extension to Universal Resource Identifiers (URIs) that allow for non-ASCII characters. In addition to functioning as identifiers, IRIs are usually, but not necissarily, resolvable which means a person or machine can "dereference" them (_click on them_ or otherwise action them) and be taken to more information about the resource, perhaps in a web browser. 
 
 Subjects and objects within an RDF triple are called nodes and can also be be represented with a blank node (a local identifier with meaning outside the graph it is defined within). Objects can further be represented with a literal value. Basic literal values in RDF are those used in XML <<XSD2>> but the basic types can be extended for specialised purposes and in this specification are, for geometry data. The figure below shows a basic triple.
 
@@ -20,7 +21,7 @@ image::01.png[RDF Triple,600,400,align="center"]
 
 Note that the same node may be a subject in some triples, and an object in others.
 
-Almost all data can be presented or represented in RDF. In particular, it is an easy match to the (feature-instance-by-id, attribute, value) tuples of the General Feature Model <<ISO19109>>, and for the relational model as (table primary key, column, value).
+Almost all data can be presented or represented in RDF. In particular, it is are similarities to the (feature-instance-by-id, attribute, value) tuples of the General Feature Model <<ISO19109>>, and for the relational model as (table primary key, column, value).
 
 === SPARQL
 
@@ -90,3 +91,5 @@ This specification document follows a modular design and contains the following
 Each of these specification components forms a _requirements class_ (a set of requirements) for GeoSPARQL. Implementations can provide various levels of functionality by choosing which requirements classes to support. For example, a system based purely on qualitative spatial reasoning may support only the core and topological vocabulary components.
 
 In addition, GeoSPARQL is designed to accommodate systems based on qualitative spatial reasoning and systems based on quantitative spatial computations. Systems based on qualitative spatial reasoning, (e.g. those based on the Region Connection Calculus <<QUAL>>, <<LOGIC>>) do not usually model explicit geometries, so queries in such systems will likely test for binary spatial relationships between features rather than between explicit geometries. To allow queries for spatial relations between features in quantitative systems, GeoSPARQL defines a series of query transformation rules that expand a feature-only query into a geometry-based query. With these transformation rules, queries about spatial relations between features will have the same specification in both qualitative systems and quantitative systems. The qualitative system will likely evaluate the query with a backward-chaining spatial “reasoner”, and the quantitative system can transform the query into a geometry-based query that can be evaluated with computational geometry.
+
+:sectnums:

spec/sections/04-conformance.adoc

@@ -1,11 +1,11 @@
 == Conformance
-Conformance with this specification shall be checked using all the relevant tests specified in _Annex A — Abstract Test Suite_. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in _ISO 19105: Geographic information — Conformance and Testing_ <<ISO19105>>.
+Conformance with this specification shall be checked using all the relevant tests specified in <<Abstract Test Suite (normative)>>. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in _ISO 19105: Geographic information — Conformance and Testing_ <<ISO19105>>.
 
 This document establishes several requirements classes and corresponding conformance classes (a conformance class is a set of tests for each requirement in a requirements class). Any GeoSPARQL implementation claiming conformance with one of the conformance classes shall pass all the tests in the associated abstract test suite.
 
-Requirements and conformance tests have IRIs that are relative to versioned namespace IRIs. Requirements and conformance test that are defined in GeoSPARQL 1.0 have IRIs relative to  `http://www.opengis.net/spec/geosparql/1.0/`, requirements and conformance test that are added in GeoSPARQL 1.1 have IRIs relative to  `http://www.opengis.net/spec/geosparql/1.1/`.
+Requirements and Conformance Class tests have IRIs that are relative to versioned namespace IRIs. Requirements and conformance test that are defined in GeoSPARQL 1.0 have IRIs relative to  `http://www.opengis.net/spec/geosparql/1.0/`, requirements and conformance test that are added in GeoSPARQL 1.1 have IRIs relative to  `http://www.opengis.net/spec/geosparql/1.1/`.
 
-Many conformance classes are parameterized. For parameterized conformance classes, the list of parameters is given within parenthesis.
+Many Conformance Classes are parameterized. For parameterized conformance classes, the list of parameters is given within parenthesis.
 
 [#conformance_classes,%autowidth]
 .Conformance Classes
@@ -23,6 +23,9 @@ Many conformance classes are parameterized. For parameterized conformance classe
 (serialization, version) 
 
 | Defines geometry vocabulary and non-topological query functions | xref:/conf/geometry-extension[]
+
+| Geometry Extension - DGGS | Defines the properties and functions of the Geometry Extension Conformance Classes for use with Discrete Global Grid System geometry representations | xref:/conf/geometry-extension-dggs[]
+
 |Geometry Topology Extension 
 
 (serialization, version, relation_family) 

spec/sections/11-geometry_extension.adoc

@@ -58,9 +58,11 @@ SFA-CA also describes M coordinate values that may be part of geometry encodings
 SFA-CA specifies a class hierarchy for Geometry. Although these classes are not part of the GeoSPARQL ontology, the GeoSPARQL SWG does publish a vocabulary of Simple Features geometry: http://www.opengis.net/ont/sf. Geometry types defined in this vocabulary can be considered safe to use with GeoSPARQL. The two Geometry serializations that were specified in GeoSPARQL 1.0, WKT and GML, fully support all SFA-CA geometry types. However, the two Geometry serializations that were introduced in GeoSPARQL 1.1 do not. Some SFA-CA geometry types are not supported by either the OGC KML <<OGCKML>> or the GeoJSON format. For example, neither KML nor GeoJSON support the Triangulated Integrated Network (TIN) or Triangle geometry types.
 
 === Recommendation for units of measure
+
 For geometric data to be interpreted and used correctly, the units of measure should be known. Typically, the particular Spatial Reference System (SRS) that is associated with a Geometry instance will specify a unit of measurement. However, some elements of GeoSPARQL allow arbitrary units of distance to be used, for example the property <<Property: geo:hasSpatialResolution, `geo:hasSpatialResolution`>> or the function <<Function: geof:buffer, `geof:buffer`>>. In those cases it is advisable to make use of a well-known web vocabulary for units of measurement. Making the unit of measurement explicit will improve data interoperability. The recommended vocabulary for units of measurement for GeoSPARQL is the _Quantities, Units, Dimensions and Types (QUDT)_ ontologyfootnote:[http://www.qudt.org] but others may be used, as long as they are well-described.
 
 === Influence of Reference Systems on computations
+
 A Geometry object consists of a set of coordinates and a specification on how the coordinates should be interpreted. This specification is known as a Spatial reference System (SRS). Taken together, coordinates and SRS allow performing computations on Geometry objects. For example, sizes can be calculated or new Geometry objects can be created. Some Spatial Reference Systems describe a two-dimensional flat space. In that case, coordinates are understood to be Cartesian, and Cartesian geometric computations can be performed. But Spatial Reference Systems can describe other types of spaces, to which Cartesian computations are not applicable. For example, if CRS http://www.opengis.net/def/crs/OGC/1.3/CRS84[`+<http://www.opengis.net/def/crs/OGC/1.3/CRS84>+`] is used, coordinates are to be interpreted as decimal degrees of latitude and longitude, designating positions on a spheroid. The distance between two points using this CRS is different from the distance between two points that have the same coordinates but are based on a Cartesian CRS or other SRS.
 
 To avoid erroneous computations involving Geometry, data publishers are recommended to clearly indicate the type of space that is described by the SRS.
@@ -369,6 +371,7 @@ this property is the generic property used to connect a Geometry with its serial
 ====
 
 === Geometry Serializations
+
 This section establishes the Requirements class for representing Geometry data in RDF literals, according to different non-RDF systems.
 
 GeoSPARQL presents specializations of the `geo:hasSerialization` property for indicating particular serializations and specialized datatype literals for containing them. It does not provide comprehensive definitions of their content since these are given in standards external to GeoSPARQL, all of which are referenced.

spec/sections/12-geometry_topology_extension.adoc

@@ -10,7 +10,7 @@ The Dimensionally Extended Nine Intersection Model (DE-9IM) <<DE-9IM>> has been
 * `F` (false) = `{-1}`
 * `*` (don't care) = `{-1, 0, 1, 2}`
 
-In the following descriptions, the notation `X/Y` is used to denote applying a spatial relation to geometry types `X` and `Y` (i.e., `x` _relation_ `y` where `x` is of type `X` and `y` is of type `Y`). The symbol `P` is used for 0-dimensional geometries (e.g. points). The symbol `L` is used for 1- dimensional geometries (e.g. lines), and the symbol `A` is used for 2-dimensional geometries (e.g. polygons). Consult the Simple Features specification <<OGCSFACA>> <<ISO19125-1>> for a more detailed description of DE-9IM intersection patterns.
+In the following descriptions, the notation `X/Y` is used to denote applying a spatial relation to geometry types `X` and `Y` (i.e., `x` _relation_ `y` where `x` is of type `X` and `y` is of type `Y`). The symbol `P` is used for 0-dimensional geometries (e.g., points). The symbol `L` is used for 1- dimensional geometries (e.g. lines), and the symbol `A` is used for 2-dimensional geometries (e.g. polygons). Consult the Simple Features specification <<OGCSFACA>> <<ISO19125-1>> for a more detailed description of DE-9IM intersection patterns.
 
 [requirements_class,identifier="/req/geometry-topology-extension",subject="Implementation Specification"]
 .Geometry Topology Extension

spec/sections/14-query_rewrite_extension.adoc

@@ -1,6 +1,6 @@
 == Query Rewrite Extension
 
-This clause establishes the _Query Rewrite Extension_ parameterized Requirements class with base IRI `/req/query-rewrite-extension`, which has a single corresponding conformance class _Query Rewrite Extension_, with IRI `/conf/query-rewrite-extension`. These Requirements define a set of RIF rules <<RIF>> that use topological extension functions defined in Clause 9 to establish the existence of direct topological predicates defined in Clause 7. One possible implementation strategy is to transform a given query by expanding a triple pattern involving a direct spatial predicate into a series of triple patterns and an invocation of the corresponding extension function as specified in the RIF rule.
+This clause establishes the _Query Rewrite Extension_ parameterized Requirements class with base IRI `/req/query-rewrite-extension`, which has a single corresponding conformance class _Query Rewrite Extension_, with IRI `/conf/query-rewrite-extension`. These Requirements define a set of RIF rules <<RIF>> that use topological extension functions defined in <<geometry_extension>> to establish the existence of direct topological predicates defined in <<vocabulary_extension>>. One possible implementation strategy is to transform a given query by expanding a triple pattern involving a direct spatial predicate into a series of triple patterns and an invocation of the corresponding extension function as specified in the RIF rule.
 
 [requirements_class,identifier="/req/query-rewrite-extension",subject="Implementation Specification"]
 .Query Rewrite Extension

spec/sections/aa-abstract_test_suite.adoc

@@ -3,7 +3,7 @@
 == Abstract Test Suite
 
 [discrete]
-=== A. 0. Overview
+=== A.0. Overview
 
 This Annex lists tests for the Conformance Classes defined in the main body sections of this Specification with links to their Requirements and test purpose method and type.
 Conformance classes may be used to signify the compatibility of a given implementation to parts of the GeoSPARQL standard.