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 <[email protected]
<mailto:[email protected]>> 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
