- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 13 Nov 2009 16:35:47 +0000
- To: Bernard Vatant <bernard.vatant@mondeca.com>
- Cc: "Sandhaus, Evan" <sandhes@nytimes.com>, Pat Hayes <phayes@ihmc.us>, SKOS <public-esw-thes@w3.org>
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 > I think the example we have been > discussing for a week clearly belongs to this category. There are more > subtle cases of ambiguity, already discussed at large in the past > without > clear solution, like what do we do with Berlin having a single URI in > DBpedia and two different ones at least in Geonames with distinct > referents > (the populated place and the administrative division). > > Bernard > > 2009/11/13 Sandhaus, Evan <sandhes@nytimes.com> > >> Just a quick thought to throw fuel on the fire with respect to SKOS >> and >> owl:sameAs. >> >> The question is asked. Can we declare a resource R of type >> skos:concept to >> be owl:sameAs a resource S which is of some "real-world" type (say >> person, >> place, etc)? To make this assertion, it is argued, would be to >> assert that >> S is a skos:concept, which to many (though not me) seems nonsense. >> >> It is suggested by some that perhaps we instead say that R is >> skos:[exactMatch|closeMatch|narrow|broader] to S. However, it >> turns out >> that the range of these properties is skos:concept, so you are again >> asserting that S is of type skos:concept. >> >> So you don't really resolve this dilemma using skos predicates, you >> just >> make it slightly more obscure. >> >> I am of the mind however, that skos:concept(s) need not be mutually >> exclusive from their real world counterparts. After all, when one >> examines >> the indexing vocabulary of (say) a book and finds the subject heading >> "United States of America" that heading is at once both a "subject >> heading/concept" and - it seems to me - inarguably also a country. >> The >> fundamental question seems to be can a subject heading at once >> signify and >> be an object. And, at least to my mind, I think it can. >> >> Does this square with the exact language of the SKOS recommendation? >> Probably not, but - since the original intent of skos - was to >> provide a >> framework for expressing indexing vocabularies (knowledge >> organization >> systems), it seems (to me) very much in keeping with the spirit of >> the >> effort. >> >> Anyways, that's my $0.02. >> >> All the best, >> >> Evan Sandhaus >> >> -- >> Evan Sandhaus >> Semantic Technologist >> New York Times Research + Development >> @kansandhaus >> (212)556-3826 >> >> >> >> >> > > > -- > 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 16:36:22 UTC