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

Dear Antoine,

Thank you very much for creating the wiki page, it is good to have such a 
place to share the knowledge.
I will send you request for update once I have more to share :)

With best regards,
Hong




From:   Antoine Isaac <aisaac@few.vu.nl>
To:     Hong Sun/AXIFX/AGFA@AGFA
Cc:     <public-esw-thes@w3.org>, Jos De Roo/AMDUS/AGFA@AGFA, Giovanni 
Mels/AMCOH/AGFA@AGFA
Date:   08/04/2013 06:06 PM
Subject:        Re: ISSUES on disjoint of skos:exactMatch and 
skos:broaderTransitve  (skos:broadMatch)



Dear Hong,

Thanks a lot for sharing all this!
The need you've identified could be indeed shared by many others.  In fact 
there was some stuff available here and there...

I've just created a new page on the SKOS wiki, trying to summarize all I 
know--sorry for these I've forgotten.
http://www.w3.org/2001/sw/wiki/SKOS/Validation

Feel free to add any details there, or to create sub-pages in that space, 
if you want to add a lot :-)

Best regards,

Antoine


> Dear Antoine,
>
> Thank you very much for your kind and detailed explanation!
>
> I agree with your claim to keep the constraint on mapping level. In the 
case I reported, it make sense to put the pattern as non-consistant, but I 
understand there might be other cases do not wish to see this constraint 
in SKOS specification.
>
> In fact, we have a set of SKOS rules made by Giovanni Mels, expressed as 
N3 rules.
> These rules are shared here: 
_http://eulersharp.sourceforge.net/2003/03swap/skos-rules_ <
http://eulersharp.sourceforge.net/2003/03swap/skos-rules.html>.
> We use EYE N3 rule engine (_http://eulersharp.sourceforge.net/_) to 
execute these rules.
>
> Now the problem is that I can not simply add a new rule to our existing 
SKOS-Rules to detect the pattern I reported. This is because our SKOS 
Rules are created strictly following the SKOS specification. If I add an 
integrity constraint for the pattern { ?x skos:exactMatch ?y. ?x 
skos:broaderTransitive ?y. } in our rules, we can not name it as 
SKOS-rules any more as it is taking constraint check that is not stated in 
SKOS specification.
>
> Therefore, I created an extra rule set to hold constraints which is not 
explicitly stated in SKOS specification, but still considered as best to 
avoid.
> The rule is shared at 
_http://eulersharp.sourceforge.net/2003/03swap/skos-extra-rules_
> Currently, I only put a constraint check on { ?x skos:exactMatch ?y. ?x 
skos:broaderTransitive ?y. }.
>
> Meanwhile, is it possible for SKOS to establish a space to aggregate 
those *BETTER NOT TO USE PATTERNS* (e.g. the one I reported)?
> Because although I created my skos-extra-rules, it is lack of authority. 
If a false is detect by the rule, we can not consider it as inconsistency 
defined by SKOS specification.
> But if we can collect these *BETTER NOT TO USE PATTERNS* in a place hold 
by SKOS, then when we detect such a pattern, at least we can say it is not 
recommended by SKOS.
>
> How's your opinion?
>
> Best regards,
> Hong
>
>
> */From/*/: Antoine Isaac <//_aisaac@few.vu.nl_/ <
mailto:aisaac@few.vu.nl?Subject=Re%3A%20ISSUES%20on%20disjoint%20of%20skos%3AexactMatch%20and%20skos%3AbroaderTransitve%20%20(skos%3AbroadMatch)&In-Reply-To=%3C51F12BB9.9000803%40few.vu.nl%3E&References=%3C51F12BB9.9000803%40few.vu.nl%3E
>/> *
> Date*//: Thu, 25 Jul 2013 15:44:25 +0200*
> Message-ID*//: <51F12BB9.9000803@few.vu.nl> *
> To*//: <//_public-esw-thes@w3.org_/ <
mailto:public-esw-thes@w3.org?Subject=Re%3A%20ISSUES%20on%20disjoint%20of%20skos%3AexactMatch%20and%20skos%3AbroaderTransitve%20%20(skos%3AbroadMatch)&In-Reply-To=%3C51F12BB9.9000803%40few.vu.nl%3E&References=%3C51F12BB9.9000803%40few.vu.nl%3E
>/> /
> 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*