W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2003

RE: Need compelling story on the value of ontologies in fusing location-based data

From: Rahul Singh <kingtiny@cs.cmu.edu>
Date: Tue, 24 Jun 2003 21:03:09 -0400
To: "'Thomas B. Passin'" <tpassin@comcast.net>, www-rdf-interest@w3.org
Message-ID: <000301c33ab5$8e264470$ce440280@cimds.ri.cmu.edu>

Hi Tom,

> Another problem I have with simple examples like this is that 
> it is usually obvious that some non-RDF app could also do the 
> same thing.

I don't think you are the only one that feels that way. I totally agree with
you.

In fact I'll even go so far as to say that this does not apply only to
simple examples. Any thing that we can think of doing today can be done
without RDF. A well defined problem statement, a nice closed world, a good
programmer and some if statements should do it. 

However (and I think this goes to the core of the "why RDF" debates) the
issue is not to make RDF out be some silver bullet that will solve all the
problems that have plagued computers, AI and intelligent systems. It is just
a formal way of representing data in a flexible universal format that
everyone agrees upon and decides to use. I don't think its any different
than the web services people deciding that SOAP will be used as a
communication protocol and WSDL as a description language.

So rather than trying to fit RDF as the format that will end all our
reasoning problems we should look at making it flexible enough and easy
enough for everyone to use (a real hard problem today).

And the "Why RDF" question deserves only one answer....

Why not!.

My two cents.

Regards,

Rahul Singh
http://www.cs.cmu.edu/~kingtiny


> -----Original Message-----
> From: www-rdf-interest-request@w3.org 
> [mailto:www-rdf-interest-request@w3.org] On Behalf Of Thomas B. Passin
> Sent: Tuesday, June 24, 2003 8:25 PM
> To: www-rdf-interest@w3.org
> Subject: Re: Need compelling story on the value of ontologies 
> in fusing location-based data
> 
> 
> 
> [Danny Ayers
> 
> > > It would be *extremely* cool if, by consulting an OWL Location 
> > > ontology, an application could recognize that the 
> location specified 
> > > in document 2 is located *within* the bounding box specified in 
> > > document 1.  Such an example would get a *lot* of people in my 
> > > community very excited about OWL and RDFS.  Unfortunately, I can 
> > > think of nothing in OWL or RDFS that would help with this (I am 
> > > eager to be proven wrong).  /Roger
> >
> > An application could easily do just that - it's only simple 
> arithmetic
> after
> > all. Consider the application a service, orthogonal to the 
> logic. The 
> > difficult part is expressing the information in an 
> unambiguous fashion
> that
> > could be shared amongst the applications. As well as the input data 
> > you
> have
> > here, presumably you would need a way of expressing the result 
> > returned
> from
> > a SWS, A isInside B or whatever - thanks RDF/XML. To reason 
> with this
> you'd
> > presumably need to be able to state things like {X isInside A}
> disJointFrom
> > {Y isInside A} - thanks OWL. The good bit is that none of 
> this system 
> > is hard-wired (apart from the specific service), it's all entirely 
> > pluggable using declarations.
> >
> 
> But Danny, the OWL ontology cannot tell Roger's app what to 
> do with the data that it classifies as "inside" (what it 
> "means" to be "inside").  His app has to know that beforehand.
> 
> Roger, can you make something of the CityWithARiver example 
> from a few weeks back?
> 
> Another problem I have with simple examples like this is that 
> it is usually obvious that some non-RDF app could also do the 
> same thing.  Sometimes all it would take would be the right 
> database query, and any database person would see that.  Not 
> only do you have to come up with a good-sounding example, but 
> you have to tie it to the advantages that RDF/Ontologies/etc 
> could bring, instead of just creating yet another database.
> 
> Cheers,
> 
> Tom P.
> 
> 
> 
Received on Tuesday, 24 June 2003 21:03:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:59 GMT