Re: Restpark - Minimal RESTful API for querying RDF triples

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