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

Chris Bizer wrote:
> Hi Hugh and Richard,
>
> interesting discussion indeed. 
>
> I think that the basic idea of the Semantic Web is that you reuse existing
> terms or at least provide mappings from your terms to existing ones.
>
> As DBpedia is often used as an interlinking hub between different datasets
> on the Web, it should in my opinion clearly have a type b) ontology using
> Richard's classification.
>
> But what does this mean for WEB ontology languages?
>
> Looking at the current discussion, I feel reassured that if you want to do
> WEB stuff, you should not move beyond RDFS, even aim lower and only use a
> subset of RDFS (basically only rdf:type, rdfs:subClassOf and
> rdfs:subPropertyOf) plus owl:SameAs. Anything beyond this seems to impose
> too tight restrictions, seems to be too complicated even for people with
> fair Semantic Web knowledge, and seems to break immediately when people
> start to set links between different schemata/ontologies.
>
> Dublin Core and FOAF went down this road. And maybe DBpedia should do the
> same (meaning to remove most range and domain restrictions and only keep the
> class and property hierarchy).
>
> Can anybody of the ontology folks tell me convincing use cases where the
> current range and domain restrictions are useful? 
>
> (Validation does not count as WEB ontology languages are not designed for
> validation and XML schema should be used instead if tight validation is
> required).
>
> If not, I would opt for removing the restrictions.
>   
Chris,

In the Linked Data Web  restrictions are inherently loose. 

I think we've already established that the "Ontology" moniker should be 
dropped for a clearer "Schema" moniker re. what was initially labeled 
"DBpedia Ontology". By scoping the schema to the data set, we take away 
the immediate confusion i.e., DBpedia ontology is not equivalent to 
UMBEL, Yago, or OpenCyc

If the Web is becoming a real Graph Model Distributed Database were the 
Entities in the Database are defined formally via a Data Dictionary, the 
utility of Domain and Range should be self-describing and obvious. For 
starters, higher level user interaction solution pursuits will benefit 
immensely from exploitation of domain, range, and other aspects of OWL.

Simple scenario:
Try visualizing the implementation of an interface such as the one used 
by Freebase atop DBpedia's data set without the ability to deductively 
interact with an associated Data Dictionary that's endowed with some 
Description Logics.

UMBEL, OpenCyc, Yago, and eventually, a DBpedia Schema variant 
integrated with any one of:  UMBEL (OpenCyc + Popular Shared Ontology 
Integration), OpenCyc, or Yago, is the route I see for building a 
coherent high-level interface atop DBpedia for none RDF geeks. And by 
this I mean: an interface that deductively organizes data presentation 
by property type (*which is what you see when you look at the Freebase 
UI which exploits their proprietary data dictionary*).



Kingsley
> Cheers
>
> Chris
>
>
> -----Ursprüngliche Nachricht-----
> Von: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org] Im
> Auftrag von Hugh Glaser
> Gesendet: Montag, 17. November 2008 23:33
> An: Richard Cyganiak
> Cc: public-lod@w3.org; Semantic Web;
> dbpedia-discussion@lists.sourceforge.net
> Betreff: 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
>
>
>
>
>   


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Tuesday, 18 November 2008 14:54:22 UTC