Re: broader and broaderMatch... and BT??? - follow-up remark

Hi Johan,

On Fri, Feb 13, 2009 at 09:18:34AM +0100, Johan De Smedt wrote:
> Dear,
> 
> Just as a follow-up remark,
> I think the following three clauses form an inconsistency in the SKOS reference
> 
> - 10.1 (preamble on matching properties) first par:
> "The SKOS mapping properties are skos:closeMatch, skos:exactMatch, skos:broaderMatch, skos:narrowerMatch and skos:relatedMatch. These properties are used to state mapping (alignment) links between SKOS concepts in different concept schemes, where the links are inherent in the meaning of the linked concepts."
> 
> - S45: skos:closeMatch and skos:exactMatch are each instances of owl:SymmetricProperty
> 
> - S46: skos:exactMatch is an instance of owl:TransitiveProperty
> 
> Hence, inference with SKOS on a graph using skos:exactMatch may lead to concepts being in exactMatch with themselves.
> (which is obviously a mapping relation between concept[s] in the same concept scheme)

Yes, applications will have to deal with the special case where X
skos:exactMatch X has been inferred. I would expect most applications
to simply ignore such statements.

If you are concerned about the formal consequences of skos:exactMatch,
use skos:closeMatch instead.

This is not a formal inconsistency in the SKOS Reference, because it
is only a convention that the mapping properties are used to link
concepts in different schemes.

As stated in the SKOS Reference [1]:

""" 
The rationale behind this design is that it is hard to draw an
absolute distinction between internal links within a concept scheme
and mapping links between concept schemes. This is especially true in
an open environment where different people might re-organise concepts
into concept schemes in different ways. What one person views as two
concept schemes with mapping links between, another might view as one
single concept scheme with internal links only. This specification
allows both points of view to co-exist, which (it is hoped) will
promote flexibility and innovation in the re-use of SKOS data in the
Web.
"""

Regards,

Alistair

[1] http://www.w3.org/TR/2008/WD-skos-reference-20080829/#L4160

> 
> Sorry not to have remarked this earlier or if I missed a resolution for this.
> 
> best.
> 
> Johan
> 
> -----Original Message-----
> From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] On Behalf Of Johan De Smedt
> Sent: Friday, 13 February, 2009 09:03
> To: Alistair Miles; Christophe Dupriez
> Cc: Stephen Bounds; public-esw-thes@w3.org
> Subject: 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
> 
> 

-- 
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 17:36:11 UTC