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 Thursday, 4 August 2005 12:34:08 UTC