RE: DBpedia 3.2 release, including DBpedia Ontology and RDF links to Freebase

I second Hugh and Richard's point.

I think the job the DBPedia people are doing in trying to corral Wikipedia into order is an outstanding contribution. And it's obviously hard. Uniting the various forms of birth date and birth place for example really increases the value of the dataset.  And there's more to be done of course. I use the foaf:depiction property  in the DBpedia category-based picture browser I've been writing but many such images are not in line with the meaning of foaf:depiction.  Rather than being depictions of the subject itself, for a place they may be maps of the location or the  coat of arms; for an artist it might be an image made by the person rather than of the person. It would be great (at least for my picture book!) if these different meanings could be separated using contextual data into distinct properties. I think it far more important to reach for accuracy in the data than to worry about alignment to pre-existing ontologies developed for other purposes.

Chris Wallace

http://www.cems.uwe.ac.uk/xmlwiki/RDF/classbrowse.xq?resource=Bristol


-----Original Message-----
From: public-lod-request@w3.org on behalf of Hugh Glaser
Sent: Mon 17/11/2008 10:33 PM
To: Richard Cyganiak
Cc: public-lod@w3.org; Semantic Web; dbpedia-discussion@lists.sourceforge.net
Subject: Re: DBpedia 3.2 release, including DBpedia Ontology and RDF links   to Freebase
 

Very nicely put, Richard.
We are opening up the discussion here of when to define one's own and when to (re-)use from elsewhere.
I am a bit uncomfortable with the idea of "you should use a:b from c and d:e from f and g:h from i..."
It makes for a fragmented view of my data, and might encourage me to use things that do not capture exactly what I mean, as well as introducing dependencies with things that might change, but over which I have no control.
So far better to use ontologies of type (b) where appropriate, and define my own of type (a), which will (hopefully) be nicely constructed, and easier to understand as smallish artefacts that can be looked at as a whole.
Of course, this means we need to crack the infrastructure that does dynamic ontology mapping, etc.
Mind you, unless we have the need, we are less likely to do so.
I also think that the comments about the restrictions being a characteristic of the dataset for type (a), but more like comments on the world for type (b) are pretty good.
Hugh

On 17/11/2008 20:09, "Richard Cyganiak" <richard@cyganiak.de> wrote:



John,

Here's an observation from a bystander ...

On 17 Nov 2008, at 17:17, John Goodwin wrote:
<snip>
> This is also a good example of where (IMHO) the domain was perhaps
> over specified. For example all sorts of things could have
> publishers, and not the ones listed here. I worry that if you reuse
> DBpedia "publisher" elsewhere you could get some undesired inferences.

But are the DBpedia classes *intended* for re-use elsewhere? Or do
they simply express restrictions that apply *within DBpedia*?

I think that in general it is useful to distinguish between two
different kinds of ontologies:

a) Ontologies that express restrictions that are present in a certain
dataset. They simply express what's there in the data. In this sense,
they are like database schemas: If "Publisher" has a range of
"Person", then it means that the publisher *in this particular
dataset* is always a person. That's not an assertion about the world,
it's an assertion about the dataset. These ontologies are usually not
very re-usable.

b) Ontologies that are intended as a "lingua franca" for data exchange
between different applications. They are designed for broad re-use,
and thus usually do not add many restrictions. In this sense, they are
more like controlled vocabularies of terms. Dublin Core is probably
the prototypical example, and FOAF is another good one. They usually
don't allow as many interesting inferences.

I think that these two kinds of ontologies have very different
requirements. Ontologies that are designed for one of these roles are
quite useless if used for the other job. Ontologies that have not been
designed for either of these two roles usually fail at both.

Returning to DBpedia, my impression is that the DBpedia ontology is
intended mostly for the first role. Maybe it should be understood more
as a schema for the DBpedia dataset, and not so much as a re-usable
set of terms for use outside of the Wikipedia context. (I might be
wrong, I was not involved in its creation.)

Richard




This incoming email to UWE has been independently scanned for viruses by McAfee anti-virus software and none were detected



This email was independently scanned for viruses by McAfee anti-virus software and none were found