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

RE: notes at concepts vs notes at terms

From: Stella Dextre Clarke <sdclarke@lukehouse.demon.co.uk>
Date: Wed, 24 Aug 2005 15:30:22 +0100
To: "'Miles, AJ \(Alistair\)'" <A.J.Miles@rl.ac.uk>, <public-esw-thes@w3.org>
Cc: "'Ron Davies'" <ron@rondavies.be>
Message-ID: <006201c5a8b8$5ce5a590$0300a8c0@DELL>

Al, 
Sorry this has been a long time coming, but even if it's late I must
reply re BS8723.

I have to agree that BS 8723 is slightly ambiguous concerning the way
definitions should be applied, or I'd prefer to call it "flexible". As
the text makes clear, we don't believe definitions are strictly
necessary in a thesaurus. Scope notes have the function of clarifying
the scope of a concept, and that is normally all you need. So BS8723
tolerates definitions rather than actively encouraging them.
 
In line with this policy, we recognise that out there are all sorts of
thesaurus using definitions for a variety of different reasons. The use
with which I am most familiar is a sort of housekeeping function - as
the editor collects terms, he may at the same time collect data about
who provided the term, the definition of the term according to that
source, etc. At this stage, the terms have not been allocated to
concepts - they await structuring. Later on, a decision may be made to
treat several of the terms as synonyms, and one of them is chosen as the
preferred term to label the concept, but all of the housekeeping data
about the source of each term may be retained, in which case these are
attached firstly to the term and only secondarily to the concept. Well,
that is how I've seen definitions used and my personal preference would
be to attach them to terms. But I'm not sure I could get a consensus
about this, since some thesauri do seem to attach definitions directly
to concepts.

Ron's point probably comes from his long experience as a consultant,
trying to build systems to satisfy different thesaurus editors, and he
has probably discovered that he needs a model that will accommodate
attributes applying to non-preferred terms. That is my expectation too.
A generalised model should allow non-preferred terms to have attributes
(or are they properties?). Sorry, I'm just a layman and can't always
tell the difference between an attribute and a property, but if you make
allowances for that I'm sure you can see what I am getting at.

Maybe BS8723 should come off the fence more.... in a future edition. But
my experience is that it is quite hard to persuade everyone to do things
the same way, so I'll be quite pleased if we can get it to stick the way
it is. (And by the way, it's not even published yet! But Parts 1 and 2
are getting very close to publication. I think I just signed off the
very last draft, apart from just one diagram to be fixed.)

Oh, you asked for examples. If you look at the AAT, you'll see a lot of
non-descriptors have references to sources, although they don't go the
length of showing definitions. But even the source reference is an
example of an attribute applying to a term, not a concept.

Cheers
Stella

*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
SDClarke@LukeHouse.demon.co.uk
*****************************************************



-----Original Message-----
From: public-esw-thes-request@w3.org
[mailto:public-esw-thes-request@w3.org] On Behalf Of Miles, AJ
(Alistair)
Sent: 04 August 2005 13:34
To: public-esw-thes@w3.org
Subject: notes at concepts vs notes at terms



Hi all,

Does anyone have some concrete examples of notes (of any type) attached
to non-preferred terms in a thesaurus?  Could they post them to this
list?  

As Ron says [1] SKOS Core allows note properties to be attached only to
concepts.  This presents a basic problem for migration of existing
thesauri to a SKOS Core representation, where non-preferred terms may
have a 'source', 'definition', 'history note', 'editorial note' or
other.  I'm writing this email to begin a discussion of this issue, as
it is a significant (and deliberate) point of divergence between SKOS
Core and current thesaurus development practice.  I hope that we can
ultimately reach a common position, although I expect the resolution of
this issue to take some time (hence the nice gentle introduction I'm
giving here :)

So, the decision to restrict all SKOS Core note properties to use with
concepts only was deliberate, taken knowing full well that this would
prevent a small hurdle to migration of some existing thesauri.  I'm
going to try and justify that decision here, as a basis for further
discussion. 

I think there is a basic ambiguity in BS8723 and other standards
regarding some note properties. 

E.g. BS8723-2:200X section 6.1.2.5 'Definitions' (without directly
quoting to avoid copyright infringement) states that: a full dictionary
definition is not usually necessary to clarify how a descriptor is
intended to be used, however if a definition is wanted then a separate
note field should be used to avoid confusion with scope notes.  The
definition's source should also be recorded with the definition itself.

The example given is something like:

illuminations
DEF The designs, etc. employed in the embellishment of writing with
colors (OED).

The first interesting thing to note is that BS8723 seems to imply that
only descriptors should be given definitions, although that is not
explicitly stated.  Section 6.1.2.6 'History notes' BS8723 similarly
seems to imply that history notes should only be used with descriptors,
although again this is not explicitly stated.  I think BS8723 should be
categorical on this point, one way or the other.

The basic ambiguity I was referring to is this: under the BS8723 pattern
as above it is ambiguous whether the definition note describes the
special meaning associated with the term 'illuminations' in the context
of the given controlled vocabulary, or whether it describes the meaning
commonly attributed to the term 'illuminations' in the context of normal
discourse (which OED assumes) or some other (unspecified?) context.

SKOS Core deliberately attempts to preclude this type of confusion by
allowing you to only ever attach a definition to a concept (which may of
course have one or more lexical labels).  It can still be meaningful to
attribute the source of a definition, but at least it is clear what the
definition note is defining.  E.g. (notation3) ...

ex:conceptA a skos:Concept;
  skos:prefLabel 'Illuminations'@en;
  skos:definition [
    rdf:value 'The designs, etc. employed in the embellishment of
writing with colors.';
    dc:source 'OED';
  ];
.

My fundamental point is this: in possibly all the cases I've seen so far
(and I'm entirely open to counter-examples), notes attached to
non-preferred terms really ought to be attached to the corresponding
concept (even if they are ultimately presented to users otherwise),
because they describe information about the whole indexing unit.  BS8723
seems to support this by implying that scope notes, definitions and
history notes only ever be attached to descriptors (effectively to
concepts), and by only ever giving examples of such.  

If you absolutely must have notes describing an alternative label, we
could allow something like e.g. ...

ex:conceptA a skos:Concept;
  skos:prefLabel 'Animals';
  skos:altLabel 'Fauna';
  skos:editorialNote [
    skos:onLbl 'Fauna';
    rdf:value 'Check with Mr.X. whether to keep "Fauna".'; 
  ];
.

... with the 'skos:onLbl' property  (or something similary) being an
addition to SKOS Core.  This pattern could also be a way of handling
legacy?

Anyway, I think that'll do for starters :)

Cheers,

Al.


[1]
http://lists.w3.org/Archives/Public/public-esw-thes/2005Aug/0015.html
---
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440
Received on Wednesday, 24 August 2005 14:30:31 GMT

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