I. Abstract
The mission of the OGC Naming Authority (OGC-NA) is to provide the means through which OGC resources such as OGC documents, namespaces and ontologies can be controlled and managed such that they can provide clear and well-defined names and definitions. In the terminology defined in ISO 19135, OGC-NA is the Control Body for the register of OGC Names. This document specifies a rule for constructing OGC names that may be used for identifying definitions, as well as rules for formally representing the meanings of the definitions.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, policy, naming authority, definitions
III. Preface
This document specifies a rule for constructing OGC names that may be used for identifying definitions.
IV. Security considerations
No security considerations have been made for this document.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- OGC
- CSIRO
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
Name | Affiliation |
Gobe Hobona | OGC |
Simon Cox | CSIRO |
1. Scope
An OGC name may be provided for a definition of a type of object broadly classified as a “concept” or system parameter, including:
Coordinate Reference Systems (CRSs) and related objects.
Data types
Feature and property types
Functions
Nil values
Units of measure
The precise scope of definitions that may be identified with OGC Names is provided by the set of items in the register at http://www.opengis.net/register/ogc-na/def-type
Note that “Definitions” may be contrasted with “instances”, which shall use names constructed following rules provided in other OGC Name Type Specifications.
2. Conformance
This policy defines part 1 of the OGC name-type specification for definitions.
Conformance with this policy shall be checked using the naming rule and naming assignment policy defined in this document.
3. Terms definitions and abbreviated terms
3.1. Terms and definitions
3.1.1. Concept
unit of knowledge created by a unique combination of characteristics (source: ISO 1087‑1:2000)
3.1.2. control body
group of technical experts that makes decisions regarding the content of a register (source: ISO 19135)
3.1.3. register
set of files containing identifiers assigned to items with descriptions of the associated items (source: ISO 19135)
4. Conventions
This document uses the normative terms (SHALL, SHOULD, etc) defined in Subclause 5.3 of [OGC 06-121r3], which is based on the ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards. In particular, the word ‘shall’ (not ‘must’) is the verb form used to indicate a requirement to be strictly followed to comply with this specification.
Name production rules in this document are expressed using ABNF (IETF RFC 5324).
5. Naming Rule
This section describes the naming rule.
5.1. OGC name schemes
Two URI schemes IETF RFC 3986 are defined by OGC to provide persistent names for resources of interest in geographic information infrastructures. The generic syntax for OGC names is described in OGC Naming Authority – Procedures.
The generic syntax for OGC http URIs is
URI = "http://www.opengis.net/" OGCResource "/" ResourceSpecificPath
The generic syntax for OGC URNs is IETF RFC 5165
URN = "urn:ogc:" OGCResource ":" ResourceSpecificString
The following ABNF adapted from IETF RFC 3986 provides some basic definitions required in the rest of this document.
segment = *pchar
segment-nc = *pchar-nc
segment-nz = 1*pchar
segment-nz-nc = 1*pchar-nc
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc = unreserved / pct-encoded / sub-delims / "@"
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
5.2. Production rule for definition URIs
The basic form for an OGC name that identifies a definition shall be produced using the following rule:
OGCResource = "def"
ResourceSpecificPath = definition-type "/" authority "/" version "/" code
ResourceSpecificString = definition-type ":" authority ":" versionURN ":" codeURN
definition-type = segment-nz-nc ; a token from the register of OGC definition types1
authority = segment-nz-nc ; a token from the register of OGC authorities2
version = segment-nz-nc / "0" ; use 0 for un-versioned names
code = segment-nz-nc *( "/" segment-nz-nc )
versionURN = segment-nc ; this may be a zero-length string
codeURN = segment-nz-nc *( ":" segment-nz-nc )
“version” or “versionURN” is an optional field. For un-versioned definitions:
within the http URI form the version field shall be “0”
within the URN form versionURN shall be a zero-length string—so an un-versioned definition can be detected by a pair of colons ”::”.
The actual code may be composed of a sequence of fields delimited by ”/“ in the http URI form, or ”:” in the URN form.
Note that the register of definition types (http://www.opengis.net/register/ogc-na/def-type) was previously presented as Table 2 in the OGC Best Practice Definition identifier URNs in OGC namespace OGC 07-092r1.
Note that the register of authorities (http://www.opengis.net/register/ogc-na/authority) was previously presented as Table 1 in the OGC Best Practice Definition identifier URNs in OGC namespace OGC 07-092r1
5.3. Compact URIs
Compact URIs (CURIEs) are an abbreviation for strings that are intended to represent URIs. Their purpose is to support the definition of scoped names that map to URIs.
The URI of any definition registered in OGC-NA controlled registers may be represented in shortened form through use of CURIEs.
The skos:notation property shall be used for specifying the form of the registered CURIE.
The prov:wasDerivedFrom property shall be used for specifying the URI to which the registered CURIE applies.
An extract from an example registration is shown below in Turtle.
<http://www.opengis.net/def/curie/ogc/1.0/crs/EPSG> <http://www.w3.org/2004/02/skos/core#notation> "EPSG"^^<http://www.w3.org/2001/XMLSchema#string>.
<http://www.opengis.net/def/curie/ogc/1.0/crs/EPSG> <http://www.w3.org/ns/prov#wasDerivedFrom> <http://www.opengis.net/def/crs/EPSG/0/>.
Figure 1
The extract above makes it possible to use [EPSG:4326] in place of http://www.opengis.net/def/crs/EPSG/0/4326
5.3.1. Register of CURIEs
The OGC-NA maintains a register of CURIEs at http://www.opengis.net/def/curie. The register shall be used as a look-up for CURIEs commonly used in OGC Standards.
CURIEs recorded in the register shall be treated as case sensitive.
5.3.2. Use of Safe CURIEs
OGC Standards should only allow safe CURIEs, unless support for other forms of CURIEs is inherited from another standard (e.g. GeoSPARQL inherits its support of CURIEs from SPARQL). Safe CURIEs are specified in square brackets. For example:
the safe CURIE [EPSG:3857] may be used in an API request such as : https://example.org/foo/collections/bar/items?crs=
the safe CURIE [ogc-rel:queryables] can be used to represent the link relation type http://www.opengis.net/def/rel/ogc/1.0/queryables
[EPSG:4326],[OGC:date] can be used to represent an ordered list of coordinate reference systems e.g. as a query parameter value
5.3.3. Applying CURIEs to Coordinate Reference Systems
CURIEs representing a shortened form of the URI of a registered Coordinate Reference System (CRS) may be used as an alternative to the full URI by following the syntax below:
`{authority}:{identifier} == http://www.opengis.net/def/crs/{authority}/0/{identifier}`
For example, EPSG:4326 may be used to represent http://www.opengis.net/def/crs/EPSG/0/4326
When a CURIE is used to represent a CRS, the following shall apply:
The version segment of the URI is assumed to be equal to 0
The definition-type segment shall be assumed to be equal to crs.
The definition segment shall be assumed to be equal to def.
Therefore “EPSG” as a prefix shall expand to http://www.opengis.net/def/crs/EPSG/0/.
6. Name Assignment and Resolution
This section describes the name assignment policy.
6.1. Definition types
The register of definition types http://www.opengis.net/register/ogc-na/def-type is controlled by OGC-NA. Changes to this register (additions, deletions, and supersession) shall be initiated by a submission to the OGC Naming Authority [email protected].
6.3. Names
The register of names http://www.opengis.net/def/ is controlled by OGC-NA. Changes to this register (addition, deletion, and supersession) shall be initiated by a submission to the OGC Naming Authority [email protected].
6.4. Names for EPSG definitions
http URI form:
http://www.opengis.net/def/definitionType/EPSG/0/code
URN form:
urn:ogc:def:definitionType:EPSG::code
In this case, the ‘authority’ part of the URI is ‘EPSG’. The ‘code’ part of the URI is the EPSG ‘code’ unique identifier of the referenced definition. Alternately, the ‘code’ part of the URI can be the EPSG ‘name’ unique identifier. In this case, omission of the version number is recommended, as this is not required to identify a referenced record in the EPSG dataset and may even lead to confusion if a version number is provided.
The policy of the Survey and Positioning Committee of the International Association of Oil and Gas Producers (IOGP) is to not delete any entities. However, if a record is found to be incorrect, that record is deprecated and replaced. When this is done, the deprecation field of the deprecated record is changed from “false” to “true”. (In some implementations, “false” may be “0” or “no”, and “true” may be “1” or “yes”). Deprecated records are also termed ‘invalid records’. When retrieving any geodetic parameters from the EPSG dataset a user therefore needs to verify whether the record(s) is / are valid or invalid. The user then has two options: (1) follow the links provided and use the valid replacing record(s), a course typically followed when spatially referencing a new dataset, or (2) retrieve the invalid, deprecated record(s) in order to undo the effects of this error in an existing spatial dataset that had been spatially referenced using the incorrect records. Note that spatial referencing using (an) invalid EPSG entities will only generate errors if the data is subsequently subjected to coordinate conversions and/or transformations.
Example 1 The http URI value for EPSG CRS 3163 is:
http://www.opengis.net/def/crs/EPSG/0/3163
Example 2 The http URI value for the “WGS 84 longitude-latitude” CRS specified in Subclause B.3 of WMS 1.3 (previously referenced as CRS:84) is:
http://www.opengis.net/def/crs/OGC/1.3/CRS84
Example 3 The URN value for EPSG CRS 3163 is:
urn:ogc:def:crs:EPSG::3163
Example 4 The URN value for the “WGS 84 longitude-latitude” CRS specified in Subclause B.3 of WMS 1.3 (previously referenced as “CRS:84”) is:
urn:ogc:def:crs:OGC:1.3:CRS84
6.5. Description
Each definition shall be described using the Simple Knowledge Organization System (SKOS) vocabulary of the World Wide Web (W3C) consortium. Other vocabularies may also be used in addition to SKOS.
The following predicates are mandatory for resources:
skos:prefLabel for providing a human-readable version of a resource’s name
dcterms:created for stating the date the resource was created in the register
dcterms:modified for stating the date the resource was modified in the register (mandatory if the resource has been modified)
policy:status for indicating whether the resource is valid, retired, superseded, or under consideration
skos:definition for providing a human-readable description of the resource
rdfs:label for providing a human-readable version of a resource’s name (used for compatibility with non-SKOS systems)
An example of a definition described in SKOS is shown below.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix policy: <http://www.opengis.net/def/metamodel/ogc-na/> .
@prefix status: <http://www.opengis.net/def/status/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://www.opengis.net/def/serviceType/ogc/wcs/2.0>
rdf:type skos:Concept ;
dcterms:created "2018-03-13"^^xsd:date ;
dcterms:modified "2018-04-16"^^xsd:date ;
policy:status status:valid ;
skos:broader <http://www.opengis.net/def/serviceType/ogc/wcs>;
rdfs:label "OGC Web Coverage Service 2.0"^^xsd:string ;
rdfs:seeAlso <http://www.opengis.net/spec/wcs/2.0> ;
skos:prefLabel "OGC Web Coverage Service 2.0"@en ;
skos:definition "A Web Coverage Service (WCS) offers multi-dimensional coverage data for access over the Internet" .
6.6. Resolution of the Same Definition to Different Encodings
The definition of a resource may be accessed in any number of encodings that are supported by a resolution service or resolver. A non-exhaustive list of example encodings relevant to different resources is below:
Geography Markup Language (GML): Supports the encoding on features, coordinate reference systems, and codelists.
Well Known Text (WKT): Supports the encoding on features, and coordinate reference systems.
Simple Knowledge Organization System (SKOS) in Resource Description Framework (RDF): Supports the encoding concepts, glossaries, and thesauri
A resolution service and a client application shall negotiate the encoding format to use through the content negotiation process defined in IETF RFC 7231.
6.7. Assigning and Handling Name Aliases
Where the URI of a named resource has an alias, the OGC-NA shall entail copies of all the properties for both forms of URI, and create inverse sameAs relationships. For example, upon registering the resource example-B as an alias of example-A,
all of the properties of example-A shall be copied to example-B
the statement that example-B is sameAs example-A shall be declared
the statement that example-A is sameAs example-B shall be declared
In code, this is illustrated below.
<example-A> rdf:type skos:Concept.
<example-B> rdf:type skos:Concept.
<example-A> owl:sameAs <example-B> .
6.8. Supporting Services
In some cases, additional services may be provided by OGC Staff to facilitate the use of names or URIs that are registered with the OGC-NA. Such supporting services may be provided through a path underneath http://www.opengis.net/def or its sub-paths. The interface definition and syntax for communicating with the supporting services is out-of-scope of the responsibilities of the OGC-NA.
Examples of such supporting services include:
AUTO2 namespace for CRS: The “AUTO2” namespace is used for “automatic” coordinate reference systems; that is, for a class of CRSs that include a user-selected centre of projection. See section 6.7.3.4 of the Web Map Service (WMS) version 1.3.0 standard (OGC 06-042). Note that although the namespace is with the OGC-NA here, the syntax is instead specified in the WMS 1.3.0 standard.
AUTO namespace for CRS: The AUTO namespace is used for “automatic” projections; that is, for a class of projections that include an arbitrary center of projection. See section 6.5.5.2 of the WMS 1.1.1 standard (OGC 01-068r3). Note that although the namespace is with the OGC-NA here, the syntax is instead specified in the WMS 1.1.1 standard. The supporting service is provided at http://www.opengis.net/def/crs/AUTO
Compound CRS: See clause 6.4 of the OGC Coverage Implementation Schema with Corrigendum Standard version 1.1.1 (OGC 09-146r8). Note that although the service is provided through the OGC Definitions Server, the syntax and interface are specified in the CIS 1.1.1 standard. The supporting service is provided at http://www.opengis.net/def/crs-compound
Annex A
(informative)
Background
A.1. Introduction
This annex includes useful information from the previous document OGC 07-092r3
A.2. URNs for Coordinate Reference Systems
One frequent use of URNs is referencing the CRS for an OGC Web Service input or output; another use is referencing the CRS for a feature geometry or a bounding box. These URNs are used to identify the referenced CRS, not to transfer a definition of that CRS. Most of this material is also applicable to referencing CRS components and Coordinate Operations and their components, often referred to as objects.
NOTE 1: Subclause D.14 of [OGC 06-121r3] summarizes many of the requirements considered when specifying how to reference CRSs.
Document [OGC 06-121r3] specifies that each specific OWS shall always reference a CRS by using an XML attribute or element with the type anyURI. Such an anyURI value can be used to reference a CRS whether the definition of that CRS is included in the same data transfer, is NOT included in the same data transfer, cannot be electronically accessed, or can be electronically accessed.
NOTE 2: In XML Schemas, the anyURI data type is the standard way to briefly reference (or cite) a value specified elsewhere. XML attributes with the type anyURI include the GML defined attributes named gml:srsName, gml:uom, xlink:href, and gml:codeSpace.
When using an XML attribute or element with the type anyURI to reference a CRS, CRS-related, or other object, that URI shall have a value which uses one of two alternative URI formats:
a) Uniform Resource Locator (URL), with standard form. The URL format should be used whenever the referenced definition is known to be electronically available using this standard URL.
b) Uniform Resource Name (URN), with a specified form. The URN format shall be used whenever the referenced definition is not, or might not be, available using a URL. This URN shall reference data that is specified by some ‘authority’ and is ‘well-known’ to both client and server software, including multiple clients and multiple servers.
NOTE 3: Two widely-used forms of URI are URL and URN. We are specifying using URNs as the way of citing CRS-related definitions that are “well-known” but are not adequately electronically available using a URL.
Subclause 10.3.2 of the OWS Common specification [OGC 06-121r3] specifies when and how to use URLs to reference a CRS or CRS-related object. Use of URNs is expected to be more common than use of URLs, and specific OWS Implementation Specifications are expected to use many standard URN values.
A.3. URNs and URLs
URNs [IETF RFC 2141] are a kind of URI [IETF RFC 2396], and may be used as the value of references where a URI is required. This is often the case in GML-based encodings (e.g., the standard XML attributes xlink:href, xlink:role, xlink:arcrole, srsName, uom, codeSpace) and in OGC Web Services (OWS) operation requests and responses.
A URN serves as a persistent identifier of a resource or concept. A detailed description of the resource may also be available online, with a resource locator (URL) providing an access point. In general, there is no direct mapping or algorithm to obtain a URL for the resource designated by a URN. URNs are intended to be more persistent than URLs, so that they remain valid even if a resource description is relocated. However, a resolution service or resolver is expected to provide a URL corresponding to a URN.
A.4. URN and schema component designators
In a few places in OWS interfaces, an identifier for an XML component is required. In these cases, it is important that the identifier reference the actual schema definition, which may then be used as the template for an OWS request or response.
A number of options are available for identification of schema components. The W3C XML Schema recommendation provides QName (qualified name – see XML Schema Part 2, clause 3.2.18). A QName has the lexical form ns:name where ‘ns’ is an XML namespace prefix for which a namespace declaration is in scope. The QName thus corresponds with an identifier tuple {namespace, local name} where ‘namespace’ is the fully scoped identifier for the XML namespace. In contrast, a URN identifier is complete, and does not depend on context for resolution of the namespace prefix.
NOTE: The W3C XML activity is currently considering a more complete scheme for identification of schema components, documented in the working draft XML Schema: Component Designators http://www.w3.org/TR/xmlschema-ref/.
In OWS interfaces, XML components are generally identified using a QName.
While there is some overlap of the meaning of schema component designators with the OGC URN scheme used for dataTypes and featureTypes, it should be understood that a URN identifies the concept, and not just its XML and XML Schema implementation. Of course, the concepts denoted by identifiers from the featureType branch generally have XML Schema implementations, so direct mappings are implied. Note that the mapping may be one-to-many, for example to manage versioning of the XML schema implementation independent of versioning of the concept.
Annex B
(informative)
Revision History
Table B.1
Date | Release | Editor | Primary clauses modified | Description |
---|---|---|---|---|
2008-12-04 | 0.1 | Simon Cox | N/A | Initial draft document |
2008-12-11 | 0.1 | Arliss Whiteside | Cover, i, ii, iii, 2, 3, 5, A | Corrected format, inserted comments, and extended |
2009-04-01 | 0.1 | Simon Cox | all | Minor tweaks and corrections for consistency with the other OGC-NA documents. |
2009-05-15 | 0.2 | David Burggraf | all | Moved all references to parameterized and compound name form of URN definitions with the intention of specifying these forms in the separate documents OGC 09-054 and OGC 09-055, respectively. |
2009-05-21 | 0.2 | Simon Cox | 2, 3 | Additional normative references; Replace EBNF with ABNF |
2010-01-31 | 1.1.0 | Simon Cox | all | ABNF revised to match RFC 3986; http URI syntax made explicit |
2010-02-28 | 1.1.1 | Simon Cox | 3.2 | Specific token “0” to be used for un-versioned http URIs. |
2010-03-31 | 1.1.2 | Simon Cox | 3.2 | Amend ABNF to allow an unlimited set of fields separated by either : or / . |
2018-05-16 | 1.2 | Gobe Hobona | all | Conversion to asciidoctor asciidoc. Updated URL of def-type list. Added the Description section and SKOS example. |
2021-06-25 | 1.3 | Gobe Hobona | 5.3 | Added clause on Shortened Names of CRS’s. Fixes Issue 92. |
2022-02-16 | 1.3 | Gobe Hobona | 5.2 | Changed statement about version number to “version” or “versionURN” is an optional field. Fixes Issue 143. |
2022-02-17 | 1.3 | Gobe Hobona | 6.7 | Added clause on Assigning and Handling Name Aliases. Fixes Issue 116. |
2022-02-18 | 1.3 | Gobe Hobona | 6.8 | Added clause on supporting services. Fixes Issue 93. |
2022-02-16 | 1.3 | Gobe Hobona | all | Conversion to metanorma asciidoc. |
2024-05-15 | 1.4 | Gobe Hobona | 5.3 | Additional CURIE usage examples. |
Bibliography
[1] Gobe Hobona, Simon Cox: OGC 09-046r6, OGC Naming Authority — Procedures. Open Geospatial Consortium (2021). http://www.opengis.net/doc/POL/OGC-NA/1.3.
[2] R. Moats: IETF RFC 2141, URN Syntax. RFC Publisher (1997). https://www.rfc-editor.org/info/rfc2141.
[3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: IETF RFC 2616, Hypertext Transfer Protocol — HTTP/1.1. RFC Publisher (1999). https://www.rfc-editor.org/info/rfc2616.
[4] T. Berners-Lee, R. Fielding, L. Masinter: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. RFC Publisher (2005). https://www.rfc-editor.org/info/rfc3986.
[5] T. Hansen, T. Hardie, L. Masinter: IETF RFC 4395, Guidelines and Registration Procedures for New URI Schemes. RFC Publisher (2006). https://www.rfc-editor.org/info/rfc4395.
[6] J. Goodwin, H. Apel: IETF RFC 5141, A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO). RFC Publisher (2008). https://www.rfc-editor.org/info/rfc5141.
[7] C. Reed: IETF RFC 5165, A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC). RFC Publisher (2008). https://www.rfc-editor.org/info/rfc5165.
[8] P. Overell: IETF RFC 5234, Augmented BNF for Syntax Specifications: ABNF. RFC Publisher (2008). https://www.rfc-editor.org/info/rfc5234.
[9] ISO: ISO 1087-1:2000, Terminology work — Vocabulary — Part 1: Theory and application. International Organization for Standardization, Geneva (2000). https://www.iso.org/standard/20057.html.
[10] OGC 05-020r25, Technical Committee Policies and Procedures, http://docs.ogc.org/pol/05-020r25/05-020r25.html (2017)
[11] W3C: CURIE Syntax 1.0, https://www.w3.org/TR/curie (2010)
[12] OGC Definitions Server, Available at http://www.opengis.net/def.
[13] W3C: SKOS Simple Knowledge Organization System, https://www.w3.org/TR/skos-reference (2009)