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

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.
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> 
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*