Re: Restpark - Minimal RESTful API for querying RDF triples

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?

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> wrote:

> Hi Hugh,
>
> On Thu, Apr 18, 2013 at 10:56 AM, Hugh Glaser <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
> e: leigh@ldodds.com
>
>


-- 
-----------------------------------------------------------------------------------
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Web & Media Group | Department of Computer Science
- The Network Institute
VU University Amsterdam