- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 18 Apr 2013 11:48:43 -0400
- To: public-lod@w3.org
- Message-ID: <517015DB.3030700@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 18 April 2013 15:49:06 UTC