Re: Restpark - Minimal RESTful API for querying RDF triples

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
>