Comments on: Embedding queries in RDF – FOAF Group example http://danbri.org/words/2008/01/22/260 the web, the world, us, you and them Thu, 11 Mar 2010 21:48:30 +0000 hourly 1 By: danbri’s foaf stories » Language Expertise in FOAF: Speaks, Reads, Writes revisited http://danbri.org/words/2008/01/22/260/comment-page-1#comment-13863 danbri’s foaf stories » Language Expertise in FOAF: Speaks, Reads, Writes revisited Mon, 10 Mar 2008 14:27:05 +0000 http://danbri.org/words/2008/01/22/260#comment-13863 [...] skills in terms of group membership, could be a way to go here. This is related to the idea of expressing group-membership criteria through writing SPARQL queries: we can talk about the Group of people who work for W3C. Or we can talk about the Group of people [...] [...] skills in terms of group membership, could be a way to go here. This is related to the idea of expressing group-membership criteria through writing SPARQL queries: we can talk about the Group of people who work for W3C. Or we can talk about the Group of people [...]

]]> By: Leo Sauermann http://danbri.org/words/2008/01/22/260/comment-page-1#comment-13497 Leo Sauermann Fri, 25 Jan 2008 08:18:18 +0000 http://danbri.org/words/2008/01/22/260#comment-13497 We did a similar thing by extending the Jena engine. We augmented Jena's rules by adding sparql. Its much nicer than above thing, because the passing of parameters is much easier. Also, with rules, its obvious that "something will happen", they are by definition dynamic, whereas RDF graphs are static. And, within Jena rules, you can always express graphs using N-Triple Axioms. code is in this folder http://gnowsis.opendfki.de/browser/tags/0.8.3-alpha/gnowsis_retrieval/WEB-INF/src/org/gnowsis/retrieval/RuleQuerySparql.java documentation: http://gnowsis.opendfki.de/browser/tags/0.8.3-alpha/gnowsis_retrieval/doc/help.html We did a similar thing by extending the Jena engine.

We augmented Jena’s rules by adding sparql.
Its much nicer than above thing, because the passing of parameters is much easier. Also, with rules, its obvious that “something will happen”, they are by definition dynamic, whereas RDF graphs are static. And, within Jena rules, you can always express graphs using N-Triple Axioms.

code is in this folder
http://gnowsis.opendfki.de/browser/tags/0.8.3-alpha/gnowsis_retrieval/WEB-INF/src/org/gnowsis/retrieval/RuleQuerySparql.java

documentation:
http://gnowsis.opendfki.de/browser/tags/0.8.3-alpha/gnowsis_retrieval/doc/help.html

]]> By: ldodds http://danbri.org/words/2008/01/22/260/comment-page-1#comment-13478 ldodds Tue, 22 Jan 2008 10:06:52 +0000 http://danbri.org/words/2008/01/22/260#comment-13478 Hi Dan, Personally I like the idea of publishing and sharing queries. In fact I argued that the SPARQL protocol ought to include a "by reference" option that would allow queries to be linked to as a parameter, rather than embedded in the query string to support and encouraged that kind of usage. However I'm not so keen on the idea of embedding queries in the RDF like this. Mainly for the workflow reasons that you mention in the posting: the client needs to have a SPARQL engine, etc. An alternative, more RESTful approach would be to simply /link/ to where the data can be reconstituted. Why not just have an rdfs:seeAlso or related (sub?) property whose URI is a SPARQL endpoint query. This means that the workflow is much simpler for the client: they just have to de-reference the relevant URI. If the protocol supported by-reference queries then you still gain the benefit of sharing the query, as if I want to reuse it in other contexts I don't have to unpick it from your URI. Cheers, L. Hi Dan,

Personally I like the idea of publishing and sharing queries. In fact I argued that the SPARQL protocol ought to include a “by reference” option that would allow queries to be linked to as a parameter, rather than embedded in the query string to support and encouraged that kind of usage.

However I’m not so keen on the idea of embedding queries in the RDF like this. Mainly for the workflow reasons that you mention in the posting: the client needs to have a SPARQL engine, etc. An alternative, more RESTful approach would be to simply /link/ to where the data can be reconstituted.

Why not just have an rdfs:seeAlso or related (sub?) property whose URI is a SPARQL endpoint query. This means that the workflow is much simpler for the client: they just have to de-reference the relevant URI.

If the protocol supported by-reference queries then you still gain the benefit of sharing the query, as if I want to reuse it in other contexts I don’t have to unpick it from your URI.

Cheers,

L.

]]>