W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2005

Re: Glossary of terms relating to thesauri and faceted classifica tion

From: Charles McCathieNevile <charles@w3.org>
Date: Mon, 17 Jan 2005 14:25:05 -0500 (EST)
To: 'Thomas Baker' <thomas.baker@bi.fhg.de>
Cc: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>
Message-ID: <Pine.LNX.4.55.0501171355170.16736@homer.w3.org>

Hmmm. I think that the URI references "defined" in the SKOS specification are
RDF terms - that is, identifiers for some concepts.  Having identified the
concepts, they can be further described in the SKOS spec. In other words,
your preferred option.

The SKOS vocabulary then, is a set of such entities, which are meant to be
useful for particular ways of providing descriptions of sets of entities - an
RDF form of what a thesaurus does. Since RDF uses URIs as a way to identify
the things it relates, it is an easy shorthand in many cases to consider that
the URIs are themselves the things. In many cases the distinction doesn't
matter, but in some it does. (Hence the debate about whether you can identify
a person with a URI...)

RDF itself is similar - a collection of things identified by URIs (such as
http://www...#Description) that we use as if they were things we can grab
hold of and manipulate.

Jena doesn't really care whether the URIs it shuffles around are things,
concepts, identifers, or not. It just follows the rules.  But when we want to
use Jena to tell us something about the world, it is useful to have a
reasonably clear idea about how the URIs relate to the world - especially if
you are the person working on modelling the information. If you're just
feeding in a file you got that is said to find cheap shoes, and the result
tells you how to get cheap shoes, you probably won't care about the
distinction either. But if you have to find out why the "shoes" somebody got
are actually the "booties" that get put on your car wheel to immobilise it,
the distinction might be more relevant.

In general my understanding is that a URI in RDF is a collection of
characters that we can use to identify something so we can make descriptions
of it. The thing that is identified and described isn't actually the URI. The
fact that you could feed the URI to a web browser and get something back is a
consequence of using URIs, not necesarily a definitive answer to what the URI
represents to the people who use it.

It is of course helpful if you can at least get a decent answer about what
the URI means, and being a URI one way that seems obvious is to feed it to
something that works on the web. But should that be an HTTP GET? A Swoogle
query? A URIQA MGET? Something entirely new? If we define one of these
answers as correct, then we have lost some flexibility, and gained some
simplicity. As far as I know, the RDF specifications have tried to keep the
flexibility. I think that is the right decision.

I think RDF's use of URIs is similar to the way a language provides words (or
symbols, or movement patterns, or sound patterns) as identifiers for astract
or concrete things. The process of making them up is a bit different - RDF is
happy to use random lists of characters and a handful of key identified
relations and concepts, where written languages tend to have some of their
etymology remain present in the term, especially if it is a new term being
coined. But that is a gross generalisation - lots of people coin RDF URIs
with some clues as to the etymology in the URI, sometimes people make up
completely new words or icons or sign-language signs.

Another similarity is mathematics. "1" isn't a thing, it is a representation
of a thing. We can discuss, manipulate and use the thing it represents to
make people land at Heathrow instead of crash into the Thames, or to convince
people that England has a chance to win the Ashes series. When we do this, we
mostly don't need to know the exact relationship between "1" and what it
represents, and don't even want to know - we are too busy fudging the figures
and it doesn't change anything. But when we try to explain "6" to the people
in Australia whose inherited number system only goes up to 3 or 4, it is much
more obvious that there is some relationship, and useful to have a good story
about what it is.

Satisfied? :-) *Really* satisfied? :-) Not at all satisfied?

cheers

Chaals (who doesn't really need a lot of beer. But if I get it, sharing it
with a bunch of people would be a good thing to do with it...)

On Mon, 17 Jan 2005, 'Thomas Baker' wrote:

>
>On Mon, Jan 17, 2005 at 04:37:05PM +0100, Thomas Baker wrote:
>> > I would for now like to avoid the phrase "SKOS term", because it is not
>> > clear whether that refers to the SKOS Core vocabulary itself or instance
>> > data described using the SKOS Core vocabulary.  Better we talk about "the
>> > RDF terms of the SKOS Core vocabulary" or something like that.
>>
>> But are the terms of the SKOS Core vocabulary really
>> "RDF terms" in the sense defined in [4] and [5]?
>> Is "http://www.w3.org/2004/02/skos/core#Collection" an
>> _identifier_for_ the SKOS term "collection" (i.e., the SKOS
>> concept "collection"), or _is_ the URI the SKOS term??
>
>This questions perhaps needs to be put more explicitly.
>When the SKOS Core spec says "here are the terms of the
>SKOS Core vocabulary", what _are_ those terms, really?
>
>-- Are they conceptual entities _identified_ by URI references
>   such as "http://www.w3.org/2004/02/skos/core#Collection"?
>
>-- Or are the URI references themselves "the terms"?  And is
>   the SKOS Core vocabulary the "set of URI references"?
>
>If the latter, then I would understand the URI references to
>be "RDF terms" in the sense defined in [4] and [5].
>
>Personally, I would prefer to hear that the former was
>actually intended.
>
>Anyone who can set my mind at rest on this point gets a beer.
>Anyone who can set my mind at rest with a really satisfying
>explanation gets _alot_ of beer!
Received on Monday, 17 January 2005 19:25:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:53 GMT