W3C home > Mailing lists > Public > semantic-web@w3.org > December 2005

Re: How will the semantic web emerge: SPARQL end point and $$

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 21 Dec 2005 19:36:13 +0100
Message-Id: <4B8E98EE-F4E9-4524-8619-29FDA00BB591@bblfish.net>
Cc: <tim.glover@bt.com>, <fugu13@mac.com>, <fmanola@acm.org>, <semantic-web@w3.org>
To: Joshua Allen <joshuaa@microsoft.com>

On 21 Dec 2005, at 19:26, Joshua Allen wrote:
> I would draw exactly the opposite conclusion from the real-world data.

I am not sure what the opposite conclusion is that my arguments help  
you reach.

> However, I don't have any particular bias or religion to boost, so  
> my opinion may be unanchored.

Neither do I. We are both trying to determine where the future is  
going, and reasonable people can easily and rightly agree to disagree  
on that, as it is mostly indeterminate. Guessing the future correctly  
can make a lot of difference in how much money ends up in one's  
pocket :-)

I think at the minimum it is worth considering that SPARQL + an  
ontology can replace a lot of what the complex SOAP web services are  
trying to do. And even simplify the RESTful web services supported by  
Amazon. This is because the Ontology, the query language, and the  
results are beautifully complimentary and fundamentally tied into the  
fundamental web archictecture construct: the URI.

Henry Story

>> -----Original Message-----
>> From: Henry Story [mailto:henry.story@bblfish.net]
>> Sent: Wednesday, December 21, 2005 10:21 AM
>> To: Joshua Allen
>> Cc: tim.glover@bt.com; fugu13@mac.com; fmanola@acm.org; semantic-
>> web@w3.org
>> Subject: Re: How will the semantic web emerge: SPARQL end point  
>> and $$
>> On 21 Dec 2005, at 19:08, Joshua Allen wrote:
>>>> worth looking at this. If I were Barnes and Noble of la FNAC I  
>>>> would
>>>> try this out, before Amazon gets there.
>>> This motivation only works if there is credible evidence that
>>> Amazon is preparing to launch SPARQL endpoints, though.  And even
>>> then, only if there is evidence that such endpoints would see broad
>>> adoption.
>> Amazon as you point out below, has published web services, so that is
>> a good reason to try to do better. Furthermore those services are
>> more difficult to establish as you have to specify the query language
>> as well as the xml format. With RDF and SPARQL most of these problems
>> are already solved for you in a standard way. So life is a lot
>> easier. You have a much more powerful query mechanism, a much cleaner
>> semantics. No need to re-invent the wheel.
>>>> Once more groups get their SPARQL end points out, I forsee that  
>>>> major
>>>> players will wish to standardise on some ontologies to:
>>> I believe we have enough specific evidence to counter this
>>> prediction already.  Amazon has already exposed its business data
>>> in a variety of flavors:
>> Exactly. That proves the point that if you put data on the web that
>> has value, people will use it whatever the obstacles are, as long as
>> it the obstacles are not bigger than the time required to invest in
>> accessing it. Amazon had to use RESTful web services, invent an XML
>> format and a query language as at the time they put their service
>> online SPARQL did not exist. All of this comes out  automatically
>> from having a good ontology. The query mechanism is immediately
>> defined, and the whole thing is self documenting.
>>> 1) Web services with loose contract (POX over HTTP)
>> Most successful for complex apps.
>>> 2) Intermediate format -- RSS using some simple, well-known  
>>> extensions
>> most successful for very simple keeping up to date apps.
>>> 3) Web services using tighter schema (SOAP and WSDL)
>> Not successful. Too complicated. On the way to extinction.
>>> Can you guess the relative adoption of each style?  This is a
>>> pattern we see played out across the industry.
>> So my point is that SPARQL will replace 1. It is RESTful enough and
>> avoid having to invent a query language and an XML format.
>> Henry Story
>> http://bblfish.net/blog/
Received on Wednesday, 21 December 2005 18:36:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:49 UTC