Re: Restpark - Minimal RESTful API for querying RDF triples

On Thu, Apr 18, 2013 at 11:31 AM, Barry Norton <barry.norton@ontotext.com>wrote:

>
> 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)
>

The reason I suggest wiki is that it is an familiar interface, and it is
easy to work with both on the user and developer side. In addition, that
the wiki is browsable serves to help educate, without additional
investment. As our biggest challenge now is still uptake, anything that
makes it easier to understand how things work is a win.

In interfaces I'm involved with that are based on SPARQL underneath, I aim
to let the interested user browser the queries that are used to display the
page. For restpark that could mean also returning, as part of the response,
the actual sparql query that was used to satisfy the request. End users who
were motivated to learn more (some percent of users) would then have an
easy bridge to using a SPARQL endpoint directly.

-Alan


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