Re: SPARQL and Web 2

You don't need database engineers if you have a
user-friendly query language that ordinary humans
can understand.  I claim that MKR is such a language.
(MKR is a general purpose knowledge representation
language.  Click on link below my name for info.)

MKR has "form-based" questions -- write a statement
which gives your answer, and use a question mark
for the thing you want to find.  UNIX-shell-style
variables are used to record the answers.

Here's your query in MKR.
at view = foaf;
at view = dc;

# original query
every b isa book; {
    who := $b has dc:creator = ?;
    if $who has foaf:name = "J. K. Rowling";
    then do print od $b done;
    fi;
};

# faster query
who := ? has foaf:name = "J. K. Rowling";
book := ? has dc:creator = $who;

Dick McCullough
knowledge := man do identify od existent done;
knowledge haspart proposition list;
http://rhm.cdepot.net/
----- Original Message ----- 
From: "Gareth Andrew" <freega@freegarethandrew.org>
To: "SWIG" <semantic-web@w3.org>
Sent: Sunday, October 09, 2005 6:44 PM
Subject: 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 08:37:05 UTC