Re: OGC URIs - was RE: CRS specification

Indeed! Thanks a lot, Simon.

I wonder whether you have any objection if I link your mail from the
relevant page in the CG Wiki.

Cheers,

Andrea


On Mon, Jan 6, 2014 at 5:27 PM, Raj Singh <rsingh@opengeospatial.org> wrote:

> 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?
> >>
> >
> >
> >
>
>
>


-- 
Andrea Perego, Ph.D.
European Commission DG JRC
Institute for Environment & Sustainability
Unit H06 - Digital Earth & Reference Data
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

DE+RD Unit: http://ies.jrc.ec.europa.eu/DE

----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.