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

Re: [SKOS] exactMatch issues: ISSUE-72 ISSUE-73 ISSUE-75

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 25 Jun 2008 10:47:44 +0200
Message-ID: <48620630.9080404@few.vu.nl>
To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
CC: 'SWD WG' <public-swd-wg@w3.org>, public-esw-thes@w3.org

Hi Alistair,

Initially I would tend to favor these three positions, as I'm in favor 
of not introducing additional semantics when these actually could make 
user's life more difficult when trying to isolate the consequences of 
these semantics from the originally asserted statements.

But on a second thought there are a number of problems, which we might 
have to consider more carefully. Especially if we decide to keep 
coherent with our decision to have broadMatch as a subproperty of 
broader (which I did not like at all) which hints at our trying to get 
as much semantics as possible wrt. mapping properties.

My point would be: why not adding the axiom;  "A broadMatch B, B 
broadMatch A" entails "A exactMatch B"? That would be quite coherent 
with our allowing broader cycles [1]. If there is a cycle, it is either 
that the concepts can be considered equivalent, or that there is a big 
bug (similar to a related and a broader between the same concepts)
We could actually even go further and say that if there is a broader 
cycle, then some broadMatch statement(s) should be added...
Of course this contradicts your proposal that exactMatch is disjoint 
with broaderTransitive. But well, in my eyes this highlights actually a 
problem of coherence between this proposal and the initial decision we 
took in [1]. There is no much reason from a semantic perspective to 
disallow exactMatch when there is a broaderTransitive while we allo for 
broaderTransitive to admit cycles.

Notice that for similar reasons we could allow exactMatch to be 
transitive. Even if we don't have much experience with that, we can 
argue that it satisfies the intuitive notion of concept equivalence. And 
even if it can bring problems, they will be never as harmful as the ones 
introduced by making broadMatch a subproperty of broader. (and actually, 
the ways to sort out the broadMatch/broader problems would be the same 
as sorting out the asserted/inferred exactMatch ones)



[1] http://www.w3.org/TR/skos-reference/#L2484

> Issues 72, 73, 75
>     http://www.w3.org/2006/07/SWD/track/issues/72 - ExactMatchTransitive
>     http://www.w3.org/2006/07/SWD/track/issues/73 - ExactMatchDisjoints
>     http://www.w3.org/2006/07/SWD/track/issues/75 - ExactMatchInclusions
> Some thoughts on these issues...
> --
> Issue 72 asks, is skos:exactMatch normatively transitive?
> N.B. we have no use cases which require this to be so. I haven't spent a lot
> of time exploring the consequences of inferring the transitive closure of
> skos:exactMatch across two or more mappings, so I'm reluctant to include
> this in the data model. I would prefer to leave this open for applications
> to explore the options.
> PROPOSED: That the SKOS reference make no formal statement about the
> transitivity if skos:exactMatch. 
> I.e. we leave it open. 
> If needed, we could add a note to the SKOS reference recognising that this
> might be a useful inference pattern in some situations, but is left up to
> the application whether to treat it as transitive or not, mainly because of
> lack of experience with making inferences across two or more mappings.
> --
> Issue 73 asks, is skos:exactMatch disjoint with any other properties?
> I think that an exact match link is asserting something fundamentally
> different from a hierarchical or associative link. 
> PROPOSED: That skos:exactMatch is disjoint with each of
> skos:broaderTransitive and skos:related.
> --
> Issue 75 asks, are there any property chains involving skos:exactMatch we
> could usefully include in the SKOS data model?
> Again, we have no requirement for this.
> I suggest we leave this open too, because of lack of experience or
> requirement. I haven't spent much time thinking through the consequences of
> any such property chains, so I'm reluctant to state any normatively in the
> data model. However I'm happy to add notes to the Reference discussing these
> as potentially useful inference patterns, which can be explored in
> applications.
> PROPOSED: There are no property chain axioms in the SKOS data model
> involving skos:exactMatch
> --
> Cheers,
> Al. 
> --
> 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 Wednesday, 25 June 2008 08:48:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:48 UTC