- From: David Booth <david@dbooth.org>
- Date: Wed, 30 Jan 2013 11:31:29 -0500
- To: Graham Klyne <GK@ninebynine.org>
- Cc: Dave Reynolds <dave.e.reynolds@gmail.com>, semantic-web@w3.org
[Sorry, I accidentally hit "send" before I was finished adding a
reference.]
On Wed, 2013-01-30 at 11:30 -0500, David Booth wrote:
> On Wed, 2013-01-30 at 12:29 +0000, Graham Klyne wrote:
> > On 30/01/2013 08:47, Dave Reynolds wrote:
> > > Personally I make heavy use of SPARQL as it is, including templating (both
> > > syntactic and injecting bindings into a query execution), quite happily without
> > > the need for SPIN. When I store SPARQL queries embedded in RDF I find a simpler
> > > embedding works just fine.
> >
> > FWIW, I do similarly, and haven't felt drawn to using SPIN.
>
> Likewise. I routinely use SPARQL as a simple rules language, and
> although I think the general approach of SPIN is excellent, I use native
> SPARQL instead for a few reasons:
>
> - I'm slightly skeptical about the special use of the "?this" variable
> in SPIN.
>
> - I don't care for the SPIN serialization into RDF that shreds the
> query into tiny pieces, making it even harder to read than RDF's awful
> "reification". I understand why TopQuadrant did it that way, as it
> facilitates operations like changing namespace prefixes. But for what I
> do, I prefer to treat a SPARQL template as a simple string with
> syntactic placeholders:
http://lists.w3.org/Archives/Public/semantic-web/2012Jul/0172.html
>
> - I prefer to use SPARQL INSERT instead of CONSTRUCT for inference
> rules, so that the result of the rule goes directly into a (usually
> temporary) new named graph, rather than being returned to the client. I
> find this style of putting inferences into a temporary named graph helps
> in debugging, as you can easily see exactly what triples you got.
>
> I've done a lot of SPARQL scripts of the following form:
>
> # For maintainability I define prefixes for my graph names:
> PREFIX tempGraph: < ... >
> PREFIX sourceGraph: < ... >
> PREFIX destinationGraph: < ... >
>
> CLEAR SILENT GRAPH tempGraph: ;
>
> INSERT { GRAPH tempGraph: { ... } } # Rule consequents
> WHERE { GRAPH sourceGraph: { ... } } ; # Rule antecedents
>
> # Comment out the following lines until the rule is debugged:
> ADD GRAPH tempGraph: TO GRAPH destinationGraph: ;
> DROP SILENT GRAPH tempGraph: ;
>
> Another benefit of this kind of SPARQL script is that you can DELETE
> triples also, if needed.
>
>
>
--
David Booth, Ph.D.
http://dbooth.org/
Aaron's Law, in memory of Web prodigy and open information
advocate Aaron Swartz: http://bit.ly/USR4rx
Opinions expressed herein are my own and do not necessarily
reflect those of my employer.
Received on Wednesday, 30 January 2013 16:31:57 UTC