Re: Concept Equivalence, IFPs, skos:subjectIndicator and owl:sameAs (was Re: SKOS Guide and owl:sameAs)

Hi,

> Hmm. I don't know if we want too many things like those "reasoning 
> rules" in SKOS ...

These kinds of rules are mapping rules that are popping up everywhere. 
E.g. for persons there are different application-scenarios for 
sameness (e.g. for publication counting it does not matter if I am 
Mark@Institute1 or Mark@Institute2, but for counting publication 
output per institute I am 2 different persons :-)

Introducing a standard rule for something like that is also an 
equivalent way of doing it in the language itself. A rule is just 
something that is needed when the declarative part of the language is 
not enough. So I see no inherent problem with such a rule in SKOS.

> Well, that's all the point. See my answer to Stuart. It does not have to 
> bear any information, besides acting as a semantic hub/buffer.

Reading back I probably misunderstood you. What you are saying is: 
don't add a subjectIndicator directly to the concepts in the indexing 
vocabulary, but put a blank node in between (copying from your earlier 
mail):

a:Concept1           skos/mapping:broadMatch       _:b1
b:Concept2           skos/mapping:broadMatch       _:b1
_:b1                     skos:subjectIndicator 
b:thatResource

Then if _:b1 is instead _:b2 for b:Concept2, these blank nodes are 
merged automatically because subjectIndicator is an 
InverseFunctionalProperty.

That is indeed a nice way to solve it. The only thing I have against 
that is that it requires everyone who creates a vocabulary in SKOS to 
place the blank nodes in between

That's why I think the solution I gave (with a rule and not making 
subjectIndicator an IFP) is a little bit more robust:

  IF two instances of skos:COncept have same subjectIndicator
  THEN assert skos:exactMatch between them

...because it does not rely on people not forgetting to put the blank 
node in. The instructions are simpler: just add subjectIndicator to 
skos:COncept instances. And existing vocabularies in skos with already 
subjectIndicators need not change (I dont know if there are any yet, 
but hey ;)

On the other hand it relies on that applications implementing their 
usage of the skos:exactMatch (i.e. within search this is usually just 
combining search results from either concept witht the other's 
results). This is not needed in your solution, so applications will be 
simpler with your solution.

Cheers,
Mark.

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark

Received on Tuesday, 5 December 2006 20:00:58 UTC