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

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

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 15 Jan 2008 10:44:10 +0100
Message-ID: <478C806A.2070507@few.vu.nl>
To: Leonard Will <L.Will@willpowerinfo.co.uk>
CC: SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>

Hi Leonard,

First thank your patience and for clarifying my loose use of BT/NT. I 
guess I'm getting tired due to all these mails :-)

> 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
> 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).

That's indeed the hierarchy I intended. I had removed the mentions to 
"P" and "I" to bring the example closer to the problem of the general 
BT, which we were discussing.

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

I still it is only partly true: for many scenarios, if you expect 
documents about "EU countries" (to use your own example, which I find 
even better than mine for this purpose) I would find very natural that 
documents that were indexed with "Paris" are much less relevant than the 
ones about "France" in general.
> 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 "Everest".
> 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.

To me it is even worse: you formula. I would interpret your formula "has 
the more specific concept, part or instance" as denoting potentially 
different hierarchical paths (specialization, partition, instanciation) 
but, still, homogeneous ones (either all BTG, all BTP or BTI). What we 
have in case of mixed hierarchies can be a BT that correspond to a part 
of an instance, or a part of a part of a specialization of an instance, 
etc. Not really easy to render in language other than "has a broader 
meaning/scope" :-(

>  If you then had
> EU countries
> NTI France
> 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.

The problem is that 2 assumes that the consumption of SKOS data will be 
similar to thesaurus query expansion, and according to the specific 
strategy you support (and which I find reasons to object to, cf above).
But I think this is not the only case where we would need for instance a 
SKOS service: many use cases just aim at providing the hierarchies as 
intended by the KOS designer. And for this, as you say, if all the 
narrower terms of a concept are returned as siblings, you might get into 
trouble. You can still untangle the mess you would be served by such a 
server by re-constructing the original hierarchy yourself, but this is 
clearly sub-optimal (and might fail in some weird cases)


Received on Tuesday, 15 January 2008 09:44:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:09 UTC