W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2010

Re: URIs for Concept & ConceptScheme - best practice?

From: Alistair Miles <alimanfoo@googlemail.com>
Date: Mon, 17 May 2010 10:11:20 +0100
To: Simon Cox <simon.cox@jrc.ec.europa.eu>
Cc: public-esw-thes@w3.org
Message-ID: <20100517091120.GJ2729@skiathos>
Hi Simon,

On Fri, May 14, 2010 at 02:41:39PM +0200, Simon Cox wrote:
> I'm thinking about identifier policies for ontologies and concept-schemes. 
>  
> In work that I have done previously on identifier policies for Open
> Geospatial Consortium and for Commission for Geoscience Information we used
> the identifier scheme largely as a way to enforce certain governance
> arrangements for resource publication. The general principle is that a URI
> is composed of a number of fields. A new URI can only be minted if the
> values in all the fields are valid; the allowable value for each field must
> come from a specific register; and different parties are authorized to
> modify different registers. So we end up with a delegation system. This kind
> of scheme uses the URI structure for internal governance purposes, within
> the community. 
>  
> But http URIs have a 'path-like' structure which can be interpreted as a
> tree. Read in this way, the URI scheme impies certain relationships between
> resources, in particular 'ownership' of children by their parents.
> Notwithstanding the REST principle that information is in the representation
> and not the identifier, Cool URIs can be interpreted by users, and typically
> support navigation through tweaking the URI (many refs).  This kind of
> scheme is aimed at external users. 
>  
> Following this approach: is it smart to have the URI for a SKOS concept to
> be just an extension of the URI for the SKOS concept scheme? 
>  
> e.g. 
> <http://resource.geosciml.org/concept/
> <http://resource.geosciml.org/concept/unit-rank/bed> unit-rank/bed>
> skos:inScheme <http://resource.geosciml.org/concept/
> <http://resource.geosciml.org/concept/unit-rank> unit-rank>.
>  
> I'm assuming slash URIs, since I want the server to do most of the work,
> supporting content-negotiation, etc. 
> The advantage in this approach is that a casual user can navigate between
> parent and child by URI twiddling. 
> But possible gotchas are 
> (1) it assumes exactly one parent 
>    - it requires every concept to be in a scheme
>    - it privileges one scheme above any others (though I think there is no
> limit on the number of inScheme properties a Concept can have?)
> (2) there must be some others

I don't see any problem with this, as long as the scheme is the
definitive (i.e., authoritative) scheme for that concept.

Slightly tangential, but you might also be interested in:

http://www.cabinetoffice.gov.uk/media/308995/public_sector_uri.pdf
http://www.ivoa.net/Documents/latest/Vocabularies.html

Cheers

Alistair


>  
> I'd be interested in comments. 
>  
> 
> --------------------------------------------------------
> Simon Cox
> 
> European Commission, Joint Research Centre 
> Institute for Environment and Sustainability 
> Spatial Data Infrastructures Unit, TP 262 
> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy 
> Tel: +39 0332 78 3652 
> Fax: +39 0332 78 6325 
>  <mailto:simon.cox@jrc.ec.europa.eu> mailto:simon.cox@jrc.ec.europa.eu 
>  <http://ies.jrc.ec.europa.eu/simon-cox>
> http://ies.jrc.ec.europa.eu/simon-cox 
> 
> SDI Unit:  <http://sdi.jrc.ec.europa.eu/> http://sdi.jrc.ec.europa.eu/ 
> IES Institute:  <http://ies.jrc.ec.europa.eu/> http://ies.jrc.ec.europa.eu/ 
> JRC:  <http://www.jrc.ec.europa.eu/> http://www.jrc.ec.europa.eu/
> 
> --------------------------------------------------------
> 
>  
> 
> Any opinions expressed are personal unless otherwise indicated. 
> 
>  

-- 
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo@gmail.com
Tel: +44 (0)1865 287669
Received on Monday, 17 May 2010 09:35:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 May 2010 09:35:41 GMT