- From: Richard H. McCullough <rhm@volcano.net>
- Date: Mon, 10 Oct 2005 01:33:14 -0700
- To: "Gareth Andrew" <freega@freegarethandrew.org>, "SWIG" <semantic-web@w3.org>
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