- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 18 Apr 2013 07:14:35 -0400
- To: public-lod@w3.org
- Message-ID: <516FD59B.3050801@openlinksw.com>
On 4/18/13 6:54 AM, Paul Groth wrote: > Hi Leigh > > The 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 databases > 1) 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 <leigh@ldodds.com > <mailto:leigh@ldodds.com>> wrote: > > Hi Hugh, > > On Thu, Apr 18, 2013 at 10:56 AM, Hugh Glaser <hg@ecs.soton.ac.uk > <mailto:hg@ecs.soton.ac.uk>> 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: leigh@ldodds.com <mailto:leigh@ldodds.com> > > > > > -- > ----------------------------------------------------------------------------------- > Dr. Paul Groth (p.t.groth@vu.nl <mailto:p.t.groth@vu.nl>) > 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 18 April 2013 11:14:58 UTC