Re: SPARQL and Web 2

Hi Henry,

I just posted a rebuttal at
http://gingerhendrix.blogspot.com/2005/10/sparql-and-web-2.html
but in the interests of discussion I am reposting it here (Please excuse
the third person).

[DISCLAIMER: I have no expertise in this area, I am just a lay
commentator]


Henry Story has just posted describing SPARQL as a query language for
Web 2.0. I think all his usage examples are good, but I think he's
missed the point slightly. Henry suggests that Web 2.0 business will
expose SPARQL endpoints over web services. This isn't going to happen
for several reasons
     1. Economics: There is a lot of value stored in the databases Henry
        mentions and most companies will not want competitors/users to
        have unrestricted access to this data. Current web service APIs
        are designed so the expected value increase from user derived
        software, is likely to exceed the loss of the value in the data.
     2. Performance: Even if the data is completely open, and the
        economics doesn't come into play, performance is a major issue.
        SPARQL queries are designed to be written by Semantic Web
        engineers, much as SQL queries are designed to be written by
        database engineers. As an example, consider the following query
        
        PREFIX foaf: 
        PREFIX dc: 
        SELECT ?book
        WHERE { ?book dc:creator ?who
             ?who foaf:name "J. K. Rowling"
        }
        
        This query (if the WHERE clause is evaluated top to bottom) is
        highly inefficient, it first searches for all triples with
        property dc:creator, then filters those such that the
        dc:creator's foaf:name is "J. K. Rowling". A much more efficient
        query reverses the patterns in the WHERE clause. I believe
        automated query rewriting is beyond state of the art at the
        moment and will continue to be for the foreseeable future,
        especially when you consider the technical challenge of throwing
        inferencing into the mix, and the social challenge of open
        access (eg. consider the query "SELECT ?s ?p ?o WHERE
        { ?s ?p ?o}").
that's not to say I don't see SPARQL becoming an integral part of Web
2.0. I envisage that the next generation of back-end storage products,
will be based on triples, inferencing, and rules. SPARQL will be the
query language used to interface with the backend. At the web tier,
services will continue to be built on RESTful principles, however more
services will expose data as RDF, and publish schemas based on RDFS, OWL
etc to enhance their meaning. At the client side aggregators, smushers,
inferencers and provers will be fundamental building blocks, and
high-level special purpose APIs written to interface with them (eg.
BlogEd's RDF Javabeans classes). I think there is room for SPARQL again
at this level, but it's likely to be too general and complex for your
average application programmer.




On Mon, 2005-10-10 at 00:46 +0200, Henry Story wrote:
> I just posted this: http://blogs.sun.com/roller/page/bblfish/20051009
> 
> Web 2: know your end user
> 
> I have had a few questions regarding SPARQL where people are  
> misunderstanding the intended end user of this technology. Clearly  
> the end user of a SPARQL end point is not your mom and pops, who  
> would need a point and click interface on a device adapted to their  
> needs. No, the end user are developers. By making your database  
> available through a SPARQL end point you are allowing software  
> developers to create very powerful apps from your data that may in  
> different ways help grow your business. This is what Web 2 is all  
> about. Here are a few examples.
> 
> Imagine you are Amazon.com. You know that you don't have the  
> resources to think of all the different ways you can sell your  
> products. By making your catalog available for query in such a  
> general way you give some clever programmer a way perhaps to create a  
> tool that will end up helping you sell your goods, be they books,  
> CDs, electronic equipment or any of the other numerous things amazon  
> makes available. Amazon allready does this with their web services.  
> SPARQL would just allow them to generalise on that, by making the  
> query interface much more flexible, and dramatically reduce the  
> bandwidth required to extract information from their database.
> 
> Imgine that your are imdb, the amazingly useful Internet Movie  
> database. By making all the movie collection available trough SPARQL  
> you give some entrepreneurial programmer out there the opportunity to  
> create services that you had never yourself considered, or would  
> never have been able to put together yourself, as that service may  
> require bringing data together from disparate sources that you don't  
> control. If this new service that makes use of your data is  
> successful, you will see it in your logs, the creator of the service  
> will want quality of service guarantees so that he can satisfy his  
> own clients, and he may end up paying you some money for that guarantee.
> 
> Imagine your are running the French railways and you make all your  
> time table info available this way. Other travel services could use  
> this information to help people organize trips automatically, and so  
> use your trains more often. Others could write some small apps  
> specifically aimed at a particular audience whose aims and habits  
> they understand well, again increasing the usage of the railway in  
> the process.
> 
> Imagine you are a hotel chain. Here again the travel agencies could  
> find out if your rooms are available, and send you customers... When  
> GPS enabled phones become widely available programmers will be able  
> to integrate this information to help owners of cell phones locate a  
> hotel closest to them that has rooms to their liking.
> 
> If you are big or have information that is valuable you can create  
> your own ontology by yourself. If you are smaller you can be the  
> first to do it, and others will likely follow. Otherwise you can work  
> together with partners in your industry to create an ontology that  
> reflects the objects your business is about. The beauty of SPARQL is  
> that all the developer needs to know is your ontology, and he will  
> know how to query your service. SPARQL does not deal with the booking  
> part of it, for sure. That is where another technology will have to  
> take the relay. But it need not be very complicated. A link pointing  
> the user to a "buy" or "book" form would be enough for many cases.
> 
> 
> 
> Henry Story

Received on Monday, 10 October 2005 02:55:21 UTC