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

Mark

Mark van Assem a écrit :
> Hi Bernard,
>
> Thanks for the nice summary! Missed the middle part of the discussion 
> so took me a while before I understood that IFP = 
> inverseFunctionalProperty ;)
Oops.
>
> Another option (a variant on the last one you mention) would be to 
> drop subjectIndicator's IFP and instead have a reasoning rule in SKOS 
> that asserts skos:exactMatch between skos:subjects with the same 
> subjectIndicator. That protects from wrong usage of the 
> subjectIndicator and consequent unwanted owl:sameAs statements. Golden 
> rule is that if it is possible to use something wrongly it WILL happen ;)
Hmm. I don't know if we want too many things like those "reasoning 
rules" in SKOS ...
>
> In this solution the skos:subject values can come from existing 
> vocabularies, which still sounds more attractive to me than blank 
> nodes, because a blank node does not give any information beside the 
> subjectIndicator.
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.
> Another negative point for blank nodes is that in those solutions, 
> someone wanting to fill in a skos:subject value needs to find an 
> appropriate subjectIndicator first... each time s/he wants to annotate 
> something. A lot more work than selecting from a fixed vocabulary.
I miss your point here. The blank concept does not prevent to index 
directly on the named concepts, it is used only to bind concepts to some 
common subject indicator, and that is a process independent of indexing. 
Could be before, after, behind the scene ...

x:myDoc           skos:subject           a:Concept1
y:yourDoc         skos:subject           b:Concept2

That is usual indexing on regular, named concepts.
Then : hey, those concepts seem both to be broadly indicated by  z:foo.html

And there enters the blank node buffer ...

Bernard

<http://mondeca.wordpress.com/>

Received on Friday, 1 December 2006 17:06:46 UTC