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

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

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Tue, 15 Jan 2008 13:53:11 -0500
Message-Id: <57C63223-A164-4DE9-84FA-36F8D2E809E5@gmail.com>
Cc: Leonard Will <L.Will@willpowerinfo.co.uk>, SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>
To: "Sini, Margherita (KCEW)" <Margherita.Sini@fao.org>

Why not then make BT a synonym for isNarrowerThan. I'm not sure that  
it's a good idea to build a standard that is intended to be for wide  
consumption and needs broad understandability to be less  
understandable than possible, in order to imitate a legacy.

Regards,
Aan

On Jan 15, 2008, at 8:39 AM, Sini, Margherita (KCEW) wrote:

> Dear Alan,
>
> indeed your proposal "isBroaderThan" seems more comprehensible than
> "hasBroader".
>
> But I think will be good to keep consistency with thesauri in which  
> "A BT B"
> is actually represented as A has more broader term B... the  
> opposite would be
> "B NT A" meaning B has more narrow term A (in your case would be B
> isBroaderThan A). But I think maybe we start to create more  
> confusion if we
> change NT with "isBroaderThan"...
>
> hope this helps
> Margherita
>
> -----Original Message-----
> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
> Sent: 15 January 2008 14:22
> To: Sini, Margherita (KCEW)
> Cc: Leonard Will; SWD WG; SKOS
> Subject: Re: TR : [SKOS]: [ISSUE 44] BroaderNarrowerSemantics
>
>
> isNarrowerThan  isBroaderThan is even clearer, IMO. The test for
> clarity would be to use the predicate in a sentence and see if it
> makes sense. So compare
>
> "train" isBroaderThan "train station"
>
> vs
>
> "train station" hasBroader "train"
>
> Am I the only one who finds the first easier to understand?
>
> -Alan
>
> On Jan 15, 2008, at 3:31 AM, Sini, Margherita (KCEW) wrote:
>
>>
>> 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
>> verb:
>>
>> 	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
>> To: SWD WG; SKOS
>> 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
>>
>> 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 8.3.3.1 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. 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.
>>
>> Leonard
>> -- 
>> 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 18:53:31 GMT

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