- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Fri, 13 Nov 2009 18:35:04 +0100
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: SKOS <public-esw-thes@w3.org>
- Message-ID: <9d93ef960911130935w7b3a9cc2i88133c8d6e97f115@mail.gmail.com>
Richard Apologies for missing the main point in your previous message, using skos:closeMatch and not owl:sameAs anymore :( You are absolutely right about the absence of semantic collapse in this case. Bernard 2009/11/13 Richard Cyganiak <richard@cyganiak.de> > Bernard, > > > On 13 Nov 2009, at 14:24, Bernard Vatant wrote: > >> If you confuse your concept A for the thing X and X itself, maybe you can >> live inside your system with this. No real conflict, just superposition of >> different "views" of the same referent, a direct and an indirect one. A >> bit >> weird, but no real formal inconsistency so far, if the respective >> ontologies >> you use don't forbid it by assertions such as skos:Concept >> owl:disjointWith >> foaf:Person. >> > > Right. If I do this locally, there should be no harm. > > > But if I confuse also my concept B with the same thing X, and >> a third party puts all that together out of context, it will merge A and >> B, >> and from there clear inconsistencies will appear, like two different >> valuse >> of creation date, or two different values of dcterms:publisher. >> > > This argument holds against the use of owl:sameAs, but not against the use > of skos:closeMatch, which will not result in a "merge" of A and B; it will > only result in the conclusion that the "middle" resource X is both a > skos:Concept and a, say, foaf:Person. > > > If the >> supporting ontology says that dcterms:publisher has max cardinality 1, the >> two publishers will be inferred to be the same, merging some of their >> attributes, and so on. That's what I meant, Richard, by "trigger a >> semantic >> collapse". >> > > Again, does not apply to skos:closeMatch. Where is the "semantic collapse" > you predicted in that case? > > > If all URIs are ambiguous as Pat holds it, and I tend to agree, and >> default >> general mechanisms able to resolve this ambiguity so far, we're better be >> cautious, given the current dumbness of our systems and keep the ambiguity >> as limited as possible. Which means, when you see clearly undesirable >> consequences of overloading, don't do it. >> > > I fully agree with the sentence: When you see undesirable consequences of > overloading, don't do it. But I do not see those consequences for the use of > skos:closeMatch. Where are they? > > Richard -- Bernard Vatant Senior Consultant Vocabulary & Data Engineering Tel: +33 (0) 971 488 459 Mail: bernard.vatant@mondeca.com ---------------------------------------------------- Mondeca 3, cité Nollez 75018 Paris France Web: http://www.mondeca.com Blog: http://mondeca.wordpress.com ----------------------------------------------------
Received on Friday, 13 November 2009 17:35:38 UTC