Re: Restpark - Minimal RESTful API for querying RDF triples

This parameterised pre-stored (and approved) query idea has come up a 
few times.

My favourite name for it is Talis' 'SPARQL Stored Procedure' (though 
it's by far from a perfect analogy, it's catchy).

The version I pushed in 'Linked Open Services' research, and which the 
BBC use in production in their Linked Data Platform, is based around 
pre-stored CONSTRUCT queries and one connegs for a graph in Turtle/XML/JSON.

Wiki is one nice way to define this, but my spin was that these queries 
should themselves be managed RESTfully (in SPIN-based representation, 
for my taste, since all APIs should allow one to talk RDF... that's a 
tangent, but one I still stand by)

Barry



On 18/04/2013 16:23, Alan Ruttenberg wrote:
> Luca,
>
> In the past I have suggested a simple way to create simple restful 
> services based on SPARQL. This could easily be implemented as an 
> extension to your beginning of restpark.
>
> The idea is to have the definition of a service be a sparql query with 
> blanks, and possibly some extra annotations.
>
> For restpark, where you want to do a simple triple service with any of 
> subject, predicate or object omitted:
>
> /restpark?subject={subject}&predicate={predicate}&object={object}
>
> Imagine a wiki page with a distinct namespace for defining these 
> services, like Template in mediawiki.
>
> Within that:
>
> Title: restpark
>
> ## directive: discard-blocks-with-empty-bind
> ## directive: dont-select ?s if $subject
> ## directive: dont-select ?p if $predicate
> ## directive: dont-select ?o if $object
> select distinct ?s ?p ?o where
> { ?s ?p ?o.
>  { {BIND {$subject as ?s}. }
>  { {BIND {$object as ?s}. }
>  { {BIND {$predicate as ?p} }
> }
>
> --
>
> From this specification you can now generate (by script) a cgi to 
> handle the service.
> The title of the page names the service. The directives I made up as 
> way to make your single service allow for optional parameters and for 
> not returning the supplied parameters. The rest service is implemented 
> by substituting the rest parameters into the SPARQL query and 
> processing any directives. The supplied directives would do what they 
> says, deleting, e.g.,  { {BIND {$object as ?s}. } if $object isn't 
> supplied, and removing ?o from the select.
>
> Very many queries could be collapsed into simple rest calls with a 
> scheme like this. If you implemented it by referring to a wiki for the 
> specifications, services could be added easily, even by users of your 
> service.
>
> In fact you don't really need to compile the spec to a service in 
> advance. Simply configure apache to redirect to single script that 
> looks up the specification dynamically from the wiki, generates some 
> perl (or other easily compilable language) to implement the service, 
> then invokes it.
>
> You can expand how expressive your language for defining services by 
> adding further directives, or by bits of syntax that can be easily be 
> distinguished from SPARQL.
>
> We played around with this idea in the Neurocommons project, but 
> didn't deploy such a service as there were other issues that were more 
> pressing.
>
> Regards,
> Alan
>
>
>
>
> On Tue, Apr 16, 2013 at 1:52 PM, Luca Matteis <lmatteis@gmail.com 
> <mailto:lmatteis@gmail.com>> wrote:
>
>     I have recently created Restpark: http://lmatteis.github.io/restpark/
>
>     It's my way of pushing a standard RESTful interface for accessing
>     RDF data. Still in its very infancy but hopefully it can be
>     something to consider. I personally think the Semantic Web
>     community desperately needs a simpler protocol for querying RDF,
>     along side SPARQL. I have nothing against SPARQL, it's an
>     important standard to have. But something simpler and RESTful
>     needs to be part of the Semantic Web stack.
>
>     The entire web community is used to consuming APIs as simple HTTP
>     requests (REST). Would you imagine GitHub, Flickr, or any other
>     web-service API actually exposing SQL instead of their RESTful
>     API? It would make things a bit more complicated for third-parties
>     in my opinion, but more importantly it would make things so much
>     more complicated for services to implement.
>
>     I would love to think what the community thinks about this.
>
>     Best,
>     Luca
>
>