RE: [Proposal][SKOS-Core] New vocab for arrays of concepts

Not sure how to react to this. Half of me is really glad when you guys
come up with clever ways of representing the features we use in
thesauri; the other half worries when we come up with something so
complicated that we might discourage some people from trying to use it!
I'll leave it to you to decide whether this approach is "too
complicated" or not.

Looking at your example below, I probably have not grasped the full
subtleties of the RDF style. I do agree that the characteristics of
division are really useful stuff - provided we are considering each one
as an instance with respect to the particular array where it is being
used. I am less convinced about the general applicability of any one of
them across a scheme. And I am nervous about labelling them as
"Concepts". 

I'll try and explain what makes me nervous:
1. <aircraft by function> in Alistair's example could easily have been
named <aircraft by application> without detriment to the thesaurus and
its capability for consistent indexing and retrieval. The editor's
purpose in introducing it was just to cordon off a little group of
aircraft which have something in common. And it is not usually important
to be very precise about the nature of that "something in common". 

2. When we talk about "Concepts" in a thesaurus, we are usually
referring to the things that we want to index and/or search for in a
repository of information resources. A thesaurus is essentially a list
of indexable concepts. In order to present them as a usable list, each
concept has to be given a "preferred term" as its label, and semantic
relations between the concepts are presented as relationships between
the terms. (Optionally, concepts may have additional labels known as
"non-preferred terms" and although I have just referred to them as
labels, they are not supposed to be used for labelling!) Now, node
labels are not supposed to be used for indexing/retrieval. They are only
a construct for organising the list. If we start calling them concepts
we could find it more difficult than ever to explain to people what a
thesaurus is about.

However, what to do about all that and how to present it in RDF I'll
leave to someone else.
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: Danny Ayers [mailto:danny.ayers@gmail.com] 
Sent: 21 August 2004 13:03
To: Stella Dextre Clarke
Cc: Miles, AJ (Alistair); public-esw-thes@w3.org
Subject: Re: [Proposal][SKOS-Core] New vocab for arrays of concepts


On Sat, 21 Aug 2004 10:56:52 +0100, Stella Dextre Clarke
<sdclarke@lukehouse.demon.co.uk> wrote:
> Just a brief note on two points in Danny's message:
> 
> 1. "The label of the collection in your example: "Aircraft by 
> function" (a node label or guide term, the Wiki tells me)" The 
> thesaurus standards (ANSI/NISO Z39.19; ISO 2788; and the forthcoming 
> BS8723 all favour calling these things 'node labels' and their 
> function (according to ISO 2788 and BS8723) is either to name a facet 
> or to indicate the characteristic of division of an array. They are 
> sometimes called 'facet indicators', but this is an erroneous use of 
> the latter term. The AAT (Art & Architecture Thesaurus) calls them 
> 'guide terms' but only some of  the AAT guide terms function as node 
> labels; others are just dummy terms (i.e. deprecated for indexing) 
> creating steps in the hierarchical display. A number of other thesauri

> in the museums sector have been following AAT practice. Anyway, an 
> important thing to note is that not all node labels indicate a 
> characteristic of division. Some of them just name a facet, e.g. 
> '<entities>' or '<agents>'.

Thanks, the background is appreciated. This still suggests to me that
perhaps the node label information is too useful to hide in a literal.

I was wondering about the facet angle - when I first read Alistair's
example I thought that was the intention, that the array was more of a
view (of a facet), where the node label was a selector.

> 2. "The 'characteristic of division' seems quite important here, maybe

> 'function', 'form' or whatever could somehow be stated more 
> explicitly, perhaps as a reference to a skos:Concept with the label 
> 'function' or 'form'" Not sure where this is leading. A few 
> characteristics of division are very common, but plenty others are 
> unusual, sometimes unique, as in '<engines by fuel type>' or '<schools

> by religious denomination>'. The thesaurus editor simply devises a 
> helpful way of dividing up a collection of items according to the 
> nature of those items. So I would not see it as very practical to 
> prepare an exhaustive list of characteristics of division (except for 
> an existing thesaurus, where you could list all those that happened to

> appear in it, and the list could turn out very long.)

What I had in mind was something like the following (where A1, A2 etc
are the aircraft concepts in Alistair's example):

 <skos:Concept rdf:about="Fn">
   <skos:prefLabel>Function</skos:prefLabel>
 </skos:Concept>

  <skos:Collection rdf:about="COL1">
   <rdfs:label>Aircraft by function</rdfs:label>
   <skos:divisionCharacteristic rdf:resource="Fn" />
   <skos:members rdf:parseType="Collection">
     <skos:Concept rdf:about="A1"/>
     <skos:Concept rdf:about="A2"/>
     <skos:Concept rdf:about="A3"/>
   </skos:members>
   <skos:length>3</skos:length>
   <skos:viewUnder rdf:resource="A"/>
   <skos:ordered>false</skos:ordered>
 </skos:Collection>

Where the node label was naming the facet, then I suppose another
property, something like skos:usesFacet might be used in place of
divisionCharacteristic (or another level of term indirection added).

Cheers,
Danny.

Received on Sunday, 22 August 2004 09:20:22 UTC