Re: Astounding silence about same-ness Re: Concept Equivalence, IFPs, skos:subjectIndicator and owl:sameAs

tis 2006-11-07 klockan 12:07 +0100 skrev Bernard Vatant:
> Hi Mikael
> 
> Thanks for breaking the silence :-)
> >> There again, this story points to a current lack of expressiveness in 
> >> the whole RDF-OWL-SKOS toolkit, forbidding to say properly : Those two 
> >> things/concepts/resources describe the same thing, yes, but, er, well, 
> >> not really in the sense of owl:sameAs.
> >>     
> > Well, couldn't this be a case of "we're describing the same thing, BUT
> > we're using different descriptions" ?
> >   
> Agreed, if "different descriptions" means different formal 
> conceptualizations, IOW different resources. I had already met a strong 
> disagreement from some folks on the fact that an RDF resource *is a 
> description* in that sense. Not to confuse with rdf:Description, which 
> is actually a bag of elements for this description of the thing. We have 
> to tackle some way this level of indirection.

Well, apart from the fact that I agree with most things you've said, I
DON'T think this way of describing things is useful for all kinds of
RDF. I only mean it to apply to cases where you do explicit
conceptualizations, such as in concept schemes.

For example, if I have the two nodes _:me and _:mycar in a simple
Person/Car ontology, I see no need to complicate things - _:me can well
be owl:sameAs any other node that represents me.

But in cases where *the conceptualization itself* is described and has a
history, we need the distinction.

or so I think :-)

/Mikael

> > It seems to me that skos:Concept is an *explicit* conceptualization of
> > some thing. With a history, purpose, etc in itself, separately from the
> > thing.
> >   
> Agreed. So you need this level of indirection between the thing and the 
> resource which describes it.
> > so by using owl:sameAs, we're saying that not only are the described
> > "things" the same, but we're also using the *same* conceptualization,
> > with the same history etc.
> >   
> Absolutely. So the two descriptions/resources are merged, and that's not 
> what we want.
> > OTOH, it's certainly an interesting statement to say, well, we're
> > talking about the same thing (subjectIndicator) but we're using
> > different conceptualizations, etc.
> >   
> Certainly. But the point of Stuart is that if subjectIndicator is an 
> IFP, the logical result is the same (sorry) as if you use directly 
> owl:sameAs
> > So, in short, couldn't the answer be that we are really talking about
> > two resources - the thing and the conceptualization?
> >   
> ABSOLUTELY! I'm happy you come to this conclusion at the end of this 
> kind of Socratic dialogue. Now all my point with "hubjects" or "blank 
> subjects" is that the resource which is the thing is beyond any 
> description - otherwise you get into a recursivity loop. And subject 
> indicator is not a killer solution to that, as I discovered after 
> passing years munching this notion in OASIS Technical Committtee. The 
> subject indicator is yet another conceptualization for the thing (less 
> formal, more for humans, but the issue remains the same).
> 
> That's why I suggest this thing beyond the 
> conceptualizations/descriptions to be pointed as a really blank node, 
> using whatever relevant pointer. I have discussed this with Tom Baker 
> who did not see any formal opposition to use dc:subject here, but it's a 
> quite weird use of it. I think we really need a specific property, and 
> of course NOT an IFP.
> And I would be happy to have it in skos namespace, something like     
> skos:isConceptFor, so we would have
> 
> a:thisConcept      skos:isConceptFor      _:thingFoo
> b:thatConcept      skos:isConceptFor      _:thingFoo
> 
> The _:thingFoo balnk node having no other purpose that linking the two 
> concepts without merging them, and of course no rdf:Description whatsoever.
> 
> Well, I think I've hit that nail more than enough for now.
> 
-- 
Plus ça change, plus c'est la même chose

Received on Tuesday, 7 November 2006 11:17:38 UTC