- 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>
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 UTC