On 4/18/13 11:40 AM, Alan Ruttenberg wrote:
On Thu, Apr 18, 2013 at 11:31 AM, Barry Norton <[email protected] <mailto:[email protected]>> 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.
+1This 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 <[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
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
