W3C home > Mailing lists > Public > public-esw-thes@w3.org > April 2004

Re: URI policy for thesaurus concepts

From: Dan Brickley <danbri@w3.org>
Date: Fri, 30 Apr 2004 11:41:39 -0400
To: Bernard Vatant <bernard.vatant@mondeca.com>
Cc: "Miles, AJ (Alistair) " <A.J.Miles@rl.ac.uk>, public-esw-thes@w3.org, public-esw@w3.org
Message-ID: <20040430154139.GR25049@homer.w3.org>

* Bernard Vatant <bernard.vatant@mondeca.com> [2004-04-30 17:36+0200]
> To go along with Dan ...
> I also prefer the / approach in principle because it defines more neatly the "subject
> indicator", but consider that e.g. OWL uses fragment identifiers to define classes and
> properties ...
> Will not people be confused with OWL elements defined by
> http://example.org/myontology#class001
> and SKOS concepts defined by http://example.org/myskos/concept001

Some RDF/RDFS/OWL vocabs end in a / and others end in a # and others do
other things. This is the current state of affairs. The confusion is
only a problem because these different approaches have different
technical and standards characteristics (and those aren't well
explained, currently).

> What about namespace management?

An important but relatively independent problem, I think.

> And having, e.g. for GEMET, over 8000 different resources/concepts, if you just want to
> download the whole stuff, hmm...
> Is not it more simple to have a / namespace for a whole SKOS scheme, and # for each
> concept in it?
> We've been through this in Published Subjects TC, without clear conclusion ...

I've a few years experience using the http://xmlns.com/wordnet/1.6/Cat
etc approach, and have to say it is useful. The ability to return a
useful chunk of information from a larger dataset is something I am
reluctant to give up. Surely in the future we'll have richer (SKOS API,
RDF DAWG etc) interfaces to these datasets, but the current approach can
be implemented with a simple filetree or CGI script, and has proved
reasonably popular.

Received on Friday, 30 April 2004 12:03:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:11 UTC