On 4/18/13 6:54 AM, Paul Groth wrote:
Hi LeighThe problem is that it's really easy to write sparql queries that are inefficient when you don't know the data [1] and even when you do the flexibility of sparql means that people can easily end-up writing complex hard to process queries.What we've found in the Open Phacts project is that sparql is great for quickly specifying apis through the linked data api. So essentially, my argument is that sparql makes it easier for service providers to quickly add new data and worry about writing the efficient queries. That's why we've been really happy with the linked data api. We actually have updates to puelia that we need to tidy up that handle more complex pagination and such.Also, remember that once you have a rest api there are a lot of support services out there that make things like authentication and statistics tracking easier.Summarizing my take: 1) SPARQL is a really nice query language for graph databases1) Use the value of sparql on the service side to enable quick and flexible apis 2) Don't provide a generic sparql endpoint. It's really hard to manage unknown queries.Another way to say this is not many services allow you to execute arbitrary SQL queries on their backends, why should we do this in the linked data space?
Paul,What about the SPARQL-Protocol aspect of SPARQL? You can combine that with fine-grained ACLs (down to the personal URI level) and then offer endpoints to the public, social networks, professional networks, and other arbitrary groups.
A RESTful interface can be layered on top of SPARQL to ease introduction to Linked Data for sure, but we do have also appreciate that there is a lot more to SPARQL than is typically obvious with regards to data access and management.
Fine-grained ACLs remain the big problem here. Only when you have those in place can you have a Read-Write dimension to data access (be it via SPARQL or some purpose specific REST interaction patterns) . The issue of folks writing problematic queries never really goes away, so any service ultimately needs to be able to protect itself, accordingly.
Kingsley
cheers Paul[1] http://thinklinks.wordpress.com/2013/04/03/5-heuristics-for-writing-better-sparql-queries/On Thu, Apr 18, 2013 at 12:27 PM, Leigh Dodds <[email protected] <mailto:[email protected]>> wrote:Hi Hugh, On Thu, Apr 18, 2013 at 10:56 AM, Hugh Glaser <[email protected] <mailto:[email protected]>> wrote: > (Yes, Linked Data API is cool!, and thanks for getting back to the main subject, although I somehow doubt anyone is expecting to read anything about it in this thread now :-) ) I'm still hoping we might return to the original topic :) What this discussion, and in fact most related discussions about SPARQL as a web service, seems to overlook is that there are several different issues in play here: * Whether SPARQL is more accessible to developers than other forms of web API. For example is the learning curve, harder or easier? * Whether offering query languages like SPARQL, SQL, YQL, etc is a sensible option when offering a public API and what kinds of quality of service can be wrapped around that. Or do other forms of API offer more options for providing quality of service by trading off power of query expression? * Techniques for making SPARQL endpoints scale in scenarios where the typical query patterns are unknown (which is true of most public endpoints). Scaling and quality of service considerations for a public web service and a private enterprise endpoint are different. Not all of the techniques that people use, e.g. query timeouts or partial results, are actually standardised so plenty of scope for more exploration here. * Whether SPARQL is the only query language we need for RDF, or for more general graph databases, or whether there are room for other forms of graph query languages The Linked Data API was designed to provide a simplified read-only API that is less expressive than full SPARQL. The goals were to make something easier to use, but not preclude helping developers towards using full SPARQL if that's what they wanted. It also fills a short-fall with most Linked Data publishing approaches, i.e. that getting lists of things, possibly as a paged list, possibly with some simple filtering is not easy. We don't need a full graph query language for that. The Linked Data Platform is looking at that area too, but its also got a lot more requirements its trying to address. Cheers, L. -- Leigh Dodds Freelance Technologist Open Data, Linked Data Geek t: @ldodds w: ldodds.com <http://ldodds.com> e: [email protected] <mailto:[email protected]> -- ----------------------------------------------------------------------------------- Dr. Paul Groth ([email protected] <mailto:[email protected]>) http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/> Assistant Professor - Web & Media Group | Department of Computer Science - The Network Institute VU University Amsterdam
-- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
