Re: OGC URIs - was RE: CRS specification

Yes great explanation. It probably deserves a place on a web page somewhere...
---
Raj
The OGC: Making location count.
http://www.opengeospatial.org/ogc/organization/staff/rsingh


On Jan 5, at 10:46 PM, Simon.Cox@csiro.au wrote:

> OGC Naming Authority may have a role here, but not (currently) what you are suggesting. 
> 
> The primary role of OGC-NA is to ensure an orderly process for assigning URIs for OGC resources, such as OGC documents, standards, XML namespaces, ontologies. Individual concepts or definitions may have URIs where it is desirable that these be individually referenceable, but the definitions should be rooted in an OGC document. OGC generally has no responsibility for resources governed by other organizations, so has nothing to say about datasets, services etc, but we did find it necessary to assign URIs for some resources used in OGC standards for which the owners do not provide URIs - specifically CRSs maintained by EPSG (now know as OGP) and units of measure specified in UCUM (either or both of which are used in WMS, WFS, GML at least). In both these cases we got the OK from the resource owners for doing this (not that it was strictly necessary, but seemed a sensible courtesy) and OGC would happily deprecate the use of these if EPSG or UCUM got their act together. The OGC URI scheme was designed to include a field for the 'authority' for a definition precisely to support this case. 
> 
> The 'guideline for editors'[1] mentioned on http://www.opengeospatial.org/projects/groups/ogcnasc is for editors of documents intended for publication through OGC, which always involves the assignment of at least one URI (at least six in the case of 'standards'). The guideline does _not_ describe a general purpose process for registration of arbitrary URIs in the OGC domain, because registration generally happens only as a by-product of other activities, such as issuing an OGC standard. 
> 
> Nevertheless there is some flexibility around OGC 'definitions'. A document describing a set of definitions may specify rules that allows for definitions to be updated separately to the publication of a document, in which case the definitions and their URIs can be more dynamic. For example, as EPSG updates its register of CRS, then matching URIs in the OGC domain are implied, and OGC tries to keep a functioning resolver up to date. (One aspect OGC gave up on is the 'version number' in the URI - EPSG versions the register as a whole, but since individuals within it do not change, OGC substitutes a generic '0' as the version for all definitions - I could discuss URI versioning, but let's leave that to another time and place, please). 
> 
> The key implication for locadd here is that if you wanted OGC to register additional CRSs, this process would have to be backed by an OGC document defining the URI set and the process for maintaining the membership. This doesn't have to be heavy (either the document or the process), but it does have to be there. 
> 
> Finally - just to complete the URN vs URL story: when OGC first got into the URI game, the jury was still out on identifiers vs locators, etc, and OGC established a URN scheme. Some of the key OGC standards (WMS, WFS, GML) have traces of these bygone days, with examples showing urn:ogc:etc . Nevertheless, following a careful education campaign within OGC, in June 2010 URNs were deprecated for future use, and replaced by http URIs. The pattern for URI sets was a direct translation of the previous URN scheme with :s replaced by /s, which is why the version-number field has carried over. Unfortunately, three and a half years after the formal policy change, some OGC members have not kept up with this, so it is not entirely surprising to see some external confusion. But the locadd group should be under no misapprehension: OGC is officially right behind the use of http URIs, in order that OGC technologies can play reasonably nice with linked data and semantic web. URNs only live on in one of the OGC technologies: the ebRIM implementation of the catalogue service, because ebRIM uses URNs internally. 
> 
> And finally-finally - CSIRO currently hosts the service that provides representations of resources whose URI starts http://www.opengis.net/def/ _except_ for the crs definitions from EPSG which is hosted by OGC directly. The former is backed by an RDF store, while the latter is provided by specialized service based on SECORE software from Jacobs University which is backed by a replica of the EPSG database. Neither of the services is forever, but the URIs should be ;-)  
> 
> Simon Cox
> Chair - OGC Naming Authority
> 
> [1] https://portal.opengeospatial.org/files/48412 
> 
> -----Original Message-----
> From: Raj Singh [mailto:rsingh@opengeospatial.org] 
> Sent: Monday, 30 December 2013 4:06 PM
> To: Andrea Perego
> Cc: LocAdd W3C CG Public Mailing list
> Subject: Re: CRS specification (was: Re: ISA Core Location Vocabulary)
> 
> I would propose that you use the OGC Naming Authority, which has been set up for just this purpose. More details are here:
> http://www.opengeospatial.org/projects/groups/ogcnasc
> 
> ---
> Raj
> The OGC: Making location count.
> http://www.opengeospatial.org/ogc/organization/staff/rsingh
> 
> 
> On Dec 29, at 6:13 PM, Andrea Perego <andrea.perego@jrc.ec.europa.eu> wrote:
> 
>> 2. Should we recommend a specific CRS URI register?
>> 
> 
> 
>

Received on Monday, 6 January 2014 16:27:45 UTC