Re: Restpark - Minimal RESTful API for querying RDF triples

On 4/18/13 11:40 AM, Alan Ruttenberg wrote:
>
>
>
> On Thu, Apr 18, 2013 at 11:31 AM, Barry Norton 
> <barry.norton@ontotext.com <mailto: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.

+1

This is the kind of thing that as a community we can foster and promote, 
It's what I was trying to achieve in an earlier Twitter thread 
(referenced in one of my earlier comments) [1][2].

We should be able to spec some URL patterns which most SPARQL engine 
vendors can support, as part of the kind of *complimentary* journey 
you've just outlined.

Links:

1. https://twitter.com/stephanef/status/317650285470298112 -- a thread 
about RESTful patterns for working with ontologies and vocabularies
2. https://twitter.com/kidehen/status/317661048486363138 -- scheduled 
for implementation acknowledgement.

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


-- 

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