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

Re: SKOS-Core 1.0 Guide draft is online

From: Leonard Will <L.Will@willpowerinfo.co.uk>
Date: Mon, 15 Mar 2004 10:55:29 +0000
Message-ID: <O7ka3tGhuYVAFAhS@willpowerinfo.co.uk>
To: public-esw-thes@w3.org

In message 
<350DC7048372D31197F200902773DF4C0494415E@exchange11.rl.ac.uk> on Fri, 
12 Mar 2004, "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk> wrote
>
>I'm working on the guide to SKOS-Core 1.0, to go out with the schema next
>thursday.  I've put a draft online, no examples or diagrams yet, only the
>text.  All comments welcome.
>
><http://www.w3c.rl.ac.uk/SWAD/skos/1.0/guide/draft01.html>

Some comments, with quotes from your draft:

>To help other people unambiguously refer to your concepts without 
>having to use URIs, it is strongly recommended that no two concepts in 
>your scheme be given the same preferred label.

I would say "essential" rather than "strongly recommended".

The only exception would be when a concept has been superseded but is 
retained in the scheme for historical or backwards compatibility 
reasons. It might then have the same label as a newly defined concept. 
This takes us back to the question of how much a concept can be changed 
(by being relabelled and redefined) and still remain the same, so long 
as its URI or "concept number" is retained. How far can you modify a 
concept, and when should you delete a concept and create a new one with 
a new number?

> It is perfectly reasonable, however, to assign a concept a preferred 
>label that is also an alternative label for some other concept.

This is contrary to thesaurus practice and standards, and would cause 
problems. Labels should be unique, and are made so by the addition of a 
qualifier in parentheses if necessary.

>A concept may have one preferred label for each language, and any 
>number of alternative labels

Perhaps better rephrased as:

"A concept may have one preferred label and any number of alternative 
labels for each language"

>prodive

Minor typo in 3.i.v ; should be "provide"

>3.i.iv. RelatedSymmetric
>Use this property where all 'related' relationships between concepts 
>may be treated as being symmetric.

Should the word "all" be dropped from this? I.e. use RelatedSymmetric 
for only those relationships which are in fact symmetric?

In most conventional thesauri, "related" relationships are treated as 
symmetric, even though more precise specification would recognise that 
many of them are directional, e.g. activity/agent, process/product, 
cause/effect and so on.

If such a conventional thesaurus is encoded in SKOS format, should such 
relationships be shown as "skos:relatedSymmetric", that being the way 
they are treated, or should they be given the more general coding 
"skos:related", leaving the way open to refine the nature of the 
relationship in future?

Leonard

-- 
Willpower Information       (Partners: Dr Leonard D Will, Sheena E Will)
Information Management Consultants              Tel: +44 (0)20 8372 0092
27 Calshot Way, Enfield, Middlesex EN2 7BQ, UK. Fax: +44 (0)870 051 7276
L.Will@Willpowerinfo.co.uk               Sheena.Will@Willpowerinfo.co.uk
---------------- <URL:http://www.willpowerinfo.co.uk/> -----------------
Received on Monday, 15 March 2004 05:58:17 GMT

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