Re: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?

Evan

I suggest you read or re-read "In Defense of Ambiguity"
http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf
Actually, what you ask for, as well as Richard does, is the right to
overload (pun) URIs like you do it for names in natural languages. Following
Pat's thesis, you could indeed use the same URI to identify a library index
entry (skos:Concept) and its referent (person, country, whatever), providing
you have mechanisms allowing to sort out predicates relevant to each
interpretation of the URI. Pat's paper, IMO, has very clear proposals in
this direction. But in order to be efficient, they need general mechanisms
to deal with context. In the current state of the (semantic) web affairs,
such mechanisms are far from being implemented, so you better be careful on
what you conflate, because it will certainly be interpreted out of context,
and lead for example to identify things which are clearly distinct.

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.  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. 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".

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 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
----------------------------------------------------