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

Re: ISSUES on disjoint of skos:exactMatch and skos:broaderTransitve (skos:broadMatch)

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Thu, 25 Jul 2013 15:44:25 +0200
Message-ID: <51F12BB9.9000803@few.vu.nl>
To: <public-esw-thes@w3.org>
Dear Hong Sun,

Thanks a lot for the note, and the careful reading of the specs and minutes!

In fact I'm afraid I'll lack the time to dig things further. I *think* the resolution to issue-73 was implemented differently because the intention was to focus on constraints that apply at the level of properties dedicated to matching, not to the level where matching properties interplay with the 'normal' semantic relations.
In general at the time we felt we lacked evidence for including in the base model constraints, which would put on a same level the semantic relations most often created by humans and the matching relations very often produced by (semi-)automatic scripts...

Also, the cases that could occur, like yours, actually reflected errors that could be caught 'earlier', i.e., at the levels of original matching relationships. Namely, if one finds
<A1>  skos:exactMatch  <B1>.
<A2>  skos:exactMatch  <B1>.
There's already something fishy. Why would a concept from one scheme be exactly semantically equivalent to two different concepts from another scheme?

That being said you can of course create your own rules to do such checking, as you point out. And share these rules with the community!
I assume this will be interesting to many -- a lot of efforts on SKOS quality (qSKOS, SKOSify, ASKOSI...) have already constraints in this spirit. The point is that it may not be relevant to all; and this is what makes including such constraints in the base SKOS standard a tricky thing!

Best regards,

Antoine



> Dear Editors,
>
> I am using SKOS for terminology mapping, and wish to use SKOS for integrity check.
>
> My use case is that when mapping from one scheme A to another scheme B, I want to avoid overruling the hierarchy of the original scheme (A).
> Therefore, I want to find out bad patterns like below:
>
> <A1>  skos:broaderTransitive  <A2>.        -stated/deduced in scheme A
>
> --when the mapping is not good, I may receive the facts below during the mapping process.
> <A1>  skos:exactMatch  <B1>.                -introduced by mapping
> <A2>  skos:exactMatch  <B1>.                 -introduced by mapping
>
> As skos:exactMatch is transitive, I can then deduce <A1>  skos:exactMatch  <A2>.
>
> I would consider this deduced fact violates the skos:broaderTransitive relation stated in scheme A.
>
> But by reading the SKOS specification, _http://www.w3.org/TR/skos-reference/_
> I found skos:exactMatch is only disjoint with skos:broadMatch; there is no statement that skos:exactMatch is disjoint with skos:broaderTransitive in the spec.
> "S46 skos:exactMatch is disjoint with each of the properties skos:broadMatch and skos:relatedMatch. "
>
> Of course I can still make my rules to detect such a pattern, but then my integrity check rule is not based on SKOS any more.
>
> Meanwhile, I found in ISSUE 73, decision is made to consider skos:exactMatch is disjoint with skos:broaderTransitive (different with what finally stated on the specification)
> "2008-07-01: [rrs] RESOLVED: issue-73 is resolved by skos:exactMatch is disjoint with skos:broaderTransitive and skos:related-- _http://www.w3.org/2008/07/01-swd-minutes.html#item05_"
>
> in the mentioned minutes, it is also stated:
> *"RESOLUTION: issue-73 is resolved by skos:exactMatch is disjoint with skos:broaderTransitive and skos:related"*
>
> So my question is:
> Why the specfication did not take the decision made in ISSUE 73?
> Given the user case above, together with the decsion made in ISSUE 73, does it make sense to conside skos:exactMatch and skos:broaderTransitive as disjoint?
> Moreover, if it makes sense, then is there a small chance to make an errata on this?
>
> Thank you very much!
>
> Kind Regards,
> *
> Hong Sun | **Agfa HealthCare*
> Researcher | HE/Advanced Clinical Applications Research
> T  +32 3444 8108
>
> http://www.agfahealthcare.com <http://www.agfahealthcare.com/>
> http://blog.agfahealthcare.com <http://blog.agfahealthcare.com/>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
Received on Thursday, 25 July 2013 13:44:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:17 UTC