RE: broader and broaderMatch... and BT???

Dear,

Some considerations on best practices.

1)
I wonder if best practices could be related to different types of classification schemes.
(taxonomy, SHL, thesaurus, ...)
In case cross classification scheme searching is an objective, such matching require particular specifications to remain semantically relevant.
Obviously, these constraints may be more easy to express if mappings are made between scheme of the same type.

2)
Matching properties are among concepts in different schemes.
This limits possibilities of e.g. transitivity on matching.

3)
The properties broader, narrower and related have not been constrained to be among concepts in one concept scheme.
In practice that would seem a good practical constraint but for exchange the recommendation will not guarantee it.
In fact, matching properties being sub-properties of there non-matching variants actually infer broader from broaderMatch (and so on).
For some application this may be undesirable, hence I expect these applications will not consider the matching properties (as a best practice in their application domain).

4)
Extensions to broader, narrower typically may need a resolution as the pattern used by the SKOS extension on labels.
Defining a hierachicalRelationship class may allow to provide properties on the broader/narrower relationship.
Some of the clients I work for expressed a need for this.

5)
Likewise, the matching properties typically may need a similar resolution pattern.
Typically because mappings between concepts of different concept schemes are not always one-on-one.
A class capturing the "matching" logic/semantics could be useful.

Best, Johan. 

-----Original Message-----
From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] On Behalf Of Alistair Miles
Sent: Thursday, 12 February, 2009 19:04
To: Christophe Dupriez
Cc: Stephen Bounds; public-esw-thes@w3.org
Subject: Re: broader and broaderMatch... and BT???


Hi all,

I'm afraid it is too late in the day to consider addition of new
vocabulary to SKOS in time for the Recommendation schedule. We are
approaching candidate recommendation, and any substantive changes
needed to be considered prior to last call.

However, if there is consensus that this is an important requirement,
then I would be more than happy to provide an indication to future
working groups that this should be given further consideration.

In the mean time, anybody is of course free to publish their own
extensions to SKOS, and to disseminate them as a community practice. I
anticipate that many important requirements may only be met through
third party extensions and usage conventions established within the
community. If anyone has any suggestions as to how we might best
support such community efforts, I'd love to hear them--it is on the
agenda for the SWDWG to consider community support, but we're a bit
short of effort at the moment.

Personally, I don't find a need to introduce a sub-property of
skos:broader that is intended only for use within a single concept
scheme. I find skos:broader to be sufficient, when used in conjunction
with skos:inScheme. I also find skos:broader to correspond perfectly
well to the ISO notion of BT.

Cheers,

Alistair

On Mon, Feb 02, 2009 at 03:17:01PM +0100, Christophe Dupriez wrote:
> I like this proposal !
>
> Is it reasonable to follow it for implementation?
>
> Thanks!
>
> Christophe
>
> Stephen Bounds a écrit :
>>
>> Hi Christophe, Antoine and all,
>>
>> Personally I'm a fan of keeping SKOS terminology self-describing where  
>> possible (and therefore would argue against using "BT"/"NT"/"RT"  
>> within SKOS).
>>
>> A thought -- what about simply using:
>>
>>   skos:broadInScheme
>>   skos:narrowInScheme
>>   skos:relatedInScheme
>>
>> This would then follow a construction similar to skos:broadMatch and  
>> match the terminology of existing vocab terms such as skos:inScheme.
>>
>> Regards,
>> -- Stephen.
>>
>> Christophe Dupriez wrote:
>>> Dear Antoine,
>>>
>>> Reading this (and seing my (reasonable) difficulties to apply SKOS to 
>>> real life problems), I would like to insist that the frame defined by 
>>> previous ISO standards for thesauri be kept and supplemented. This  
>>> may seem bottom-up compared to the apparent top-down process to  
>>> define SKOS: it is alway better when stalagmites join stalagtites !
>>>
>>> For my own stuff, I will implement:
>>>
>>> skos:semanticRelation
>>> |
>>> +- skos:related
>>> |   |
>>> |   +- ???:RT
>>> |   |  (disjoint from)
>>> |   +- skos:relatedMatch
>>> |
>>> +- skos:broaderTransitive (disjoint from related and narrowerTransitive)
>>> |   |
>>> |   +- skos:broader
>>> |       |
>>> |       +- ???:BT
>>> |       |  (disjoint from)
>>> |       +- skos:broadMatch
>>> |
>>> +- skos:narrowerTransitive (disjoint from related and broaderTransitive)
>>>     |
>>>     +- skos:narrower
>>>         |
>>>         +- ???:NT
>>>         |  (disjoint from)
>>>         +- skos:narrowMatch
>>>
>>>
>>> Please note that "BT <union> broadMatch" does not cover "broader"  
>>> because "broader" may cross scheme boundaries and "BT" cannot.
>>> If you add the concept of "subScheme" (micro-thesaurus), "BT" should  
>>> not cross micro-thesaurus borders.
>>>
>>> With "RT", you can cross micro-thesaurus borders but not scheme  
>>> boundaries.
>>>
>>
>>
>>
>

> begin:vcard
> fn:Christophe Dupriez
> n:Dupriez;Christophe
> org:DESTIN inc. SSEB
> adr;quoted-printable:;;rue des Palais 44, bo=C3=AEte 1;Bruxelles;;B-1030;Belgique
> email;internet:Christophe.Dupriez@Destin.be
> title:Informaticien
> tel;work:+32/2/216.66.15
> tel;fax:+32/2/242.97.25
> tel;cell:+32/475.77.62.11
> note;quoted-printable:D=C3=A9veloppement de Syst=C3=A8mes de Traitement de l'Information
> x-mozilla-html:TRUE
> url:http://www.destin.be
> version:2.1
> end:vcard
> 


-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

Received on Friday, 13 February 2009 08:04:21 UTC