W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2013

RE: SKOS exactMatch Inclusion - a question concerning ISSUE75

From: Hong Sun <hong.sun@agfa.com>
Date: Fri, 18 Oct 2013 21:00:46 +0200
To: <vladimir.alexiev@ontotext.com>
Cc: Giovanni Mels <giovanni.mels@agfa.com>, Jos De Roo <jos.deroo@agfa.com>, <public-esw-thes@w3.org>
Message-ID: <OF30641F43.3EE23F65-ONC1257C08.006870FE-C1257C08.0068710B@agfa.com>
 Hi Vladimir,

For your comments "In that sense, it's WEAKER than broadMatch"
This is exactly what I found uncomfortable, thanks for your nice summarization.
The solutions you and Antoine suggested make sense. However, I am still cautious in adding additional features to SKOS property or define own property based on SKOS would deviate the semantic from SKOS, which may bring side effect in data sharing.
Nevertheless, I still defined a few rules [1] to carry inferences which are not endorsed in SKOS specification, but are considered as convention, following the discussions carried in SKOS community. These rules can be picked to use in optional. 
I am now hesitating in adding a third rule to [1]: 
{ ?x skos:exactMatch ?y. ?y skos:broaderTransitive ?z. } => {?x skos:broaderTransitive ?z.}.

For your suggestion on inferring exactMatch relation from broader cycle,
I agree with the comment left by Antoine that such a relation is quite probably a bug, it is therefore better to detect and report these cases rather than try to resolve it.
I have developed a set of rules to detect problematic patterns in terminology mapping [2]. In fact, it is the problematic pattern below that push me to post the question:
    ?A2 skos:broaderTransitive ?A1.
    ?A1 skos:exactMatch ?B1.
    ?B1 skos:broaderTransitive ?B2.
    ?B2 skos:exactMatch ?A2.
Intuitively, the first two triples tell ?B1 is broader (not skos:broader) than ?A2, while the last two triples tell ?A2 is broader than ?B1.
But there is no conflict according the SKOS, as well as our extra SKOS rules. I named this pattern as Counter Intuitive, and tries to look for some theory back up for it :) 

Thanks and kind regards,

[1] http://eulersharp.sourceforge.net/2003/03swap/skos-extra-rules
[2] http://lists.w3.org/Archives/Public/public-esw-thes/2013Oct/0013.html

-----"Vladimir Alexiev" <vladimir.alexiev@ontotext.com> &#25776;&#20889;:-----
 "Vladimir Alexiev" <vladimir.alexiev@ontotext.com>
 2013/10/18 &#19979;&#21320;03:27
 Giovanni Mels/AMCOH/AGFA@AGFA, Jos De Roo/AMDUS/AGFA@AGFA, <public-esw-thes@w3.org>
 RE: SKOS exactMatch Inclusion - a question concerning ISSUE75

As Johan points out, the SKOS spec is clear that nothing follows from exactMatch, nor the other way around.
exactMatch is an equivalence property (transitive and symmetric), but it doesn't follow that it's "composable" with any other transitive property like broaderTransitive.

I find this unfortunate. Here are some more considerations:

- broadMatch allows you to graft a tree from one thesaurus to another. 
But exactMatch doesn't interlink the neighborhoods of the two concepts in any way :-(
In that sense, it's WEAKER than broadMatch 

- SKOS allows "broader" cycles: http://www.w3.org/TR/skos-reference/#L2484. In such case I'd say that all the concepts in the cycle are exactMatch...
Another way of saying the same is: if <c1 broader c2> and <c1 narrower c1> then c1 <exactMatch c2>

- if <c1 foaf:focus o> and <c2 foaf:focus o> then I think should follow <c1 exactMatch c2>.
  I proposed this half a year ago, Antoine called it a "co-denotation axiom" and found it reasonable.
-- by the semantics of sameAs, the same consequence would follow from
   <c1 foaf:focus o1> and <c2 foaf:focus o2> and <o1 sameAs o2>

But like any other standard, SKOS is the result of some compromises: I guess the negators and doubters of such inferences won over in this case.

However, this does not stop you from defining yourself such axioms in your dataset. E.g.
   skos:broader owl:propertyChainAxiom (skos:broader skos:exactMatch).
Or using the PROTON ontology:
  skos:broader ptop:transitiveOver skos:exactMatch.
Received on Friday, 18 October 2013 19:01:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:46:27 UTC