OGC Name Type Specification - definitions - part 1 – basic name

unit of knowledge created by a unique combination of characteristics (source: ISO 1087‑1:2000)

group of technical experts that makes decisions regarding the content of a register (source: ISO 19135)

set of files containing identifiers assigned to items with descriptions of the associated items (source: ISO 19135)

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

The generic syntax for OGC URNs is [IETF RFC 5165]

The following ABNF adapted from [IETF RFC 3986] provides some basic definitions required in the rest of this document.

The basic form for an OGC name that identifies a definition shall be produced using the following rule:

"version" or "versionURN" is a required field. For un-versioned definitions:

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

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 names@opengeospatial.org.

The register of authorities http://www.opengis.net/register/ogc-na/authority is controlled by OGC-NA. Changes to this register (additions, deletions, and supersession) shall be initiated by a submission to the OGC Naming Authority names@opengeospatial.org.

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 names@opengeospatial.org.

http URI form:

http://www.opengis.net/def/objectType/EPSG/0/code

URN form:

urn:ogc:def:objectType: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

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:

An example of a definition described in SKOS is shown below.

This annex includes useful information from the previous document OGC 07-092r3

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) Universal 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) Universal 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.

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.

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.

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.