RE: URIs for Concept & ConceptScheme - best practice?

If I'm reading this right, there is a possible tension between CoolURIs and
REST constraints, right?

Simon

-----Original Message-----
From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org]
On Behalf Of Alistair Miles
Sent: 09 June 2010 16:08
To: public-esw-thes@w3.org
Subject: Re: URIs for Concept & ConceptScheme - best practice?

Thinking about this again, I think if I had the choice I would avoid
construction of a concept URI using some token representing the
scheme, although in some circumstances I still think this would be a
reasonable thing to do. I think I would instead choose some common
namespace for all URIs I want to coin under my authority, regardless
of whether I was coining URIs for one scheme or 20.

E.g., I would do...

http://id.mydomain.com/abcd-efgh-ijkl
http://id.mydomain.com/mnop-qrst-uvwx
etc.

My reasoning is that (1) I can imagine you might want to refactor 2 or
more schemes at some point in time, which might involve moving
concepts from one scheme to another, but don't want to have to coin a
new URI for moved concepts (and so break links), and (2) I've been
trying to swallow the *whole* REST pill lately, which means HATEOAS,
which means (link templates aside) that you shouldn't write any code
that makes assumptions about URI structure.

Actually, making these two points next to each other gives me another
thought, which is that, if you took the REST/HATEOAS view, we really
shouldn't worry about renaming things, because the web gives you a way
to manage changes in naming via redirect response codes, most usefully
301 Moved Permanently (if I remember my status codes right, sorry am
writing this offline.)

OK, so I think I will change my opinion: (1) use absolutely any URI
you like, feel free to build path segments out of the full concept
hierarchy, or whatever, and (2) make sure any code you write respects
REST constraints, in particular the hypermedia constraint (HATEOAS),
so i.e. you're code *never* depends on out-of-band information about
how the URIs where constructed, and follows links and redirects.

If I'm being pragmatic, I'd probably still go with the proposal at the
top of this email, but only because it doesn't even give people the
opportunity of breaking the hypermedia constraint.

Sorry for the mid-email change of tack, but 6 months of lurking on the
rest-discuss yahoo group is changing the way I think about semweb and
linked data :)

Cheers

Alistair


On Tue, May 18, 2010 at 02:07:00PM +0100, Rob Tice wrote:
> I would endorse Antoine's comment. 
> 
> 'And of course any cool URI tricks should not replace proper
representation
> of knowledge about the resources!'
> 
> In addition (to follow up on Mike's point): 
> 
> The process of developing ontologies/schemes etc and releasing to the
world
> (or maybe assigning URI's) when finished is only one possible approach.  
> 
> When the actual development/evolution of the concepts, schemes and
> hierarchies also has to be shared and public (even if this is only public
> within an organisation), assigning URI's based on structure just doesn't
> work well.
> 
> Cheers
> 
> Rob
> 
> 
> 
> 
> -----Original Message-----
> From: public-esw-thes-request@w3.org
[mailto:public-esw-thes-request@w3.org]
> On Behalf Of Antoine Isaac
> Sent: 18 May 2010 11:29
> To: public-esw-thes@w3.org
> Subject: Re: URIs for Concept & ConceptScheme - best practice?
> 
> Hi everyone,
> 
> > 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
> 
> 
> Very good guidelines, indeed!
> 
> About Simon's questions.
> +1 for Alistair and Johan's comments on using some concept scheme "label"
in
> the path for for the concepts that they originally coined.
> And I would advise against using the parent concepts in the path, unless
> your scheme has a strict tree structure. Otherwise you'll have to make
some
> hard choices at some places...
> 
> And of course any cool URI tricks should not replace proper representation
> of knowledge about the resources! As Rob has pointed out, the data for
some
> resources may change, making obsolete even the best patterns of the
> moment...
> 
> Cheers,
> 
> Antoine
> 
>   
> >>
> >> 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 Wednesday, 9 June 2010 14:56:20 UTC