W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2008

RE: TR : [SKOS]: [ISSUE 44] BroaderNarrowerSemantics

From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
Date: Tue, 15 Jan 2008 09:31:17 +0100
To: Leonard Will <L.Will@willpowerinfo.co.uk>, SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>
Message-id: <BA453B6B6B217B4D95AF12DBA0BFB6690269F979@hqgiex01.fao.org>

I also have the same problem referring to the ambiguity of BT (is a BT or has
BT ?), therefore I propose that the skos relationships could include the

	skos:hasBroader and skos:hasNarrower. 

This will avoid confusion.

-----Original Message-----
From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org] On
Behalf Of Leonard Will
Sent: 14 January 2008 22:47
Subject: Re: TR : [SKOS]: [ISSUE 44] BroaderNarrowerSemantics

On Mon, 14 Jan 2008 at 18:15:23, Antoine Isaac <aisaac@few.vu.nl> wrote
>I'd like to have your opinion on the example I will adapt from in [1], 
>itself adapted from Simon's previous mails

>Consider we have a thesaurus that says:

>> mountains regions BT Himalaya
>> Himalaya BT Everest

Antoine -

Just to clarify this example first, I should note that the normal convention
in thesaurus circles, and in BS8723-2, para.8.3.1, is to interpret BT as
meaning "has the broader term" and NT as "has the narrower term".  ISO 2788,
paragraph 4.1, also reads

        BT Broader term; the term that follows the symbol represents a
        concept having a wider meaning

I remember some previous discussion on the SKOS list about the ambiguity of
using these abbreviations the other way round, to mean "is the broader term
of", for example. This can easily give rise to confusion and should be sorted
out urgently. Thus I would write your example above as

mountainous regions
NT Himalaya

NT Everest

where the first is in fact an NTI relationship (i.e., for Margherita's
benefit, narrower term instantive, meaning that the proper name Himalaya is a
specific instance of a mountainous region, the reciprocal relationship being
BTI). The second is a NTP relationship (i.e. narrower term partitive, meaning
that Everest is a part of the Himalaya, reciprocal BTP).

>If BT is transitive, than for the query "give me the concepts that 
>linked tio montains regions via BT" we'll get "Himalaya" and "Everest". 
>To me (and others), this raise the following issues:

>- "mountains regions" BT "Everest" may seem questionable (especially if 
>we know this KOS to be carefully designed, following e.g. ISO2788!)

>- both concepts are now given as if siblings, losing track of the 
>initial design.
>In the end I feel that the second is the most serious one, since if we 
>go for a very rough specification of broader (fitting classification 
>schemes' idea of hierarchy for instance) we could still argue that 
>indeed there is a form a 'broader' statement between the two concepts. 
>But anyway, I'd like to have your opinion on both ;-)

I think the issue is how transitivity is to be used. The main use of a
hierarchy, apart from displaying structure and giving logical paths for
navigation, is to allow a search for a concept to be expanded to include
narrower concepts. In the generic case this is valid because the narrower
concepts are specific classes which fall within the broader concept. The
rules for indexing are generally that you allocate the most specific terms
possible to a document, and you can rely on the thesaurus to enable these
concepts to be found even when the search is expressed in broader terms.

The whole/part or "partitive" relationship can lead to problems, and
BS8723-2, paragraph says that it should normally be restricted to
four specific cases:

a) systems and organs of the body
b) geographical locations
c) disciplines or fields of discourse
d) hierarchical social structures.

The "Himalaya NTP Everest" example falls into case b), and it is reasonable
that someone searching for information about the Himalaya and any of its
parts should wish to retrieve items that have been indexed with the term

I agree that if transitivity is to work across mixed types of relationship,
we would have to interpret NT to mean "has the more specific concept, part or
instance", to generalise what Simon Spero suggested. If you then had

EU countries
NTI France

NTP Paris

it would be true to say that Paris is a more specific concept, part or
instance of an EU country. Perhaps we should adopt this meaning.

We should note, though, that this type of interpretation is used when
deciding how to expand a search using a thesaurus hierarchy. It does not
allow you to modify the hierarchy itself, by designating France and Paris as
siblings. BS8723-2, paragraph 14.3 g), specifically forbids this, saying

        Validation checks should prevent the entry of inadmissible
        relationship combinations. If two terms already have one of the
        standard relationships, no other standard relationship between
        the same terms is admissible. If term A has BT term B, none of
        the terms in the BT hierarchy above term B should be admissible
        as BT, NT or RT of term A.

This means that we cannot create a direct relationship which jumps over the
middle concept. It seems to me that we have two options:

1. If the consequence of this is that transitivity is in general not valid,
then SKOS should reflect that;

2. If we accept the generalised definition of hierarchical relationship, e.g.
using NT to mean "has the more specific concept, part or instance", then we
can assume transitivity.

I don't know which of these fits best with the purpose and approach of SKOS.
I think the decision should come from an examination of use cases.

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 Tuesday, 15 January 2008 08:31:36 GMT

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