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

RE: URIs for Concept & ConceptScheme - best practice?

From: Johan De Smedt <johan.de-smedt@tenforce.com>
Date: Fri, 14 May 2010 15:22:39 +0200
To: "'Simon Cox'" <simon.cox@jrc.ec.europa.eu>, <public-esw-thes@w3.org>
Message-ID: <4bed4ea3.0e67f10a.0301.69e5@mx.google.com>
tHi Simon,


I often use URI conventions with some relation between the URI of a concept
scheme and the URI of the concepts in that concept scheme.

Typically those schemes do not reflect any hierarchical or associative or
semantic relation between concepts.


As to your observation (1):

- hierarchies (broader/narrower) among concepts are not captured in the URI

   this protects against hierarchy changes.

- concepts that belong to multiple concept schemes can have multiple URI

  these can be linked then via owl:sameAs or skos:exactMatch (as is


Note alternative URI strategies are easy to make because a concept has the
"skos:inScheme" property to identify the concept schemes it belongs to.

Basically, the URI should be managed according the naming authorities
allowed to generate and manage the URI.

This is a possible approach from an organizational point (like international
phone numbers).

However organization structures may change as well, so naming authorities
should be identified with care.

Again, different naming authorities may identify the same concept.

(again, skos:exactMatch or owl:sameAs may accommodate this.) 


Kind Regards,

   Johan De Smedt


From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org]
On Behalf Of Simon Cox
Sent: Friday, 14 May, 2010 14:42
To: public-esw-thes@w3.org
Subject: URIs for Concept & ConceptScheme - best practice?


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? 



<http://resource.geosciml.org/concept/unit-rank/bed> skos:inScheme


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

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. 

Received on Friday, 14 May 2010 13:45:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:13 UTC