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*

Received on Sunday, 4 August 2013 16:07:03 UTC