On 03/03/14 15:47, Miguel Bento Alves wrote:
Dear All,
I'm preparing my JIRA proposal about defining SPARQL commands in rules
and/or define rules based on Sparql commands. I need your help to see if
there is any kind of overlapping between my proposal and JIRA proposal
Jena-657 (SPARQL template queries).
Is was already thought about how to define a template?
are you considering using SPIN language?
SPIN is a W3C Member Submission [1] and one of it purposes is to represent
reusable SPARQL queries as templates.
I think that my proposal should be defined considering the work to be
developed in Jena-657, with SPIN or not. SPIN is a inspiration and my
concern is about the functionality, not the implementation of SPIN himself.
So, I think that my proposal should be something like: "
Allow Jena to implement rules based on a SPARQL template (Jena-657).
Moreover, should be possible to define a Class, through clause ASK, or a
ObjectProperty based on a SPARQL template"
What do you think? Different JIRA can work close between them?
Miguel
[1] http://www.w3.org/Submission/2011/SUBM-spin-overview-20110222/
[2] http://www.w3.org/Submission/2011/SUBM-spin-sparql-20110222/
Hi Miguel,
Maybe there is some overlap with JENA-647 [*] but I don't think they are
closely related.
I haven't given much thought as to how to define a query template except
that it needs to have named slots for inserting values - SPIN is one
possibility and the Berlin SPARQL Benchmark work has a mechanism.
SELECT * { ?s ?p %value% }
and a URL with
http://server/query?ref=...&value=2000
so that the template is named by the "ref" parameter and the %value% is
replaced by 2000 (this is how the Berlin SPARQL Benchmark work that that
seems OK).
An alternative is to remain within SPARQL syntax, the template
description then says what must be defined - advantage, the
ParameterizedSparqlString can be be used which handle injection attacks.
SELECT * { ?s ?p ?value }
That said, changing the parser to handle %value% is quite easy. It
would be very valuable for ParameterizedSparqlString as well.
But for a SPARQL/Rules, I suspect any overlap is not very deep.
Instead, it would be better to design for what SPARQL/Rules needs then
to see what it fits with, not to assume the design must fit with
something else.
An RDF manipulation system using SPARQL syntax would be very useful to
have.
What's practical in the time of GSoC, which is about 3 months elapsed of
development? Even if a complete system isn't realistic, can there be
something to kick off future work?
I suggest that you start as new JIRA that is about what you want to do
and not worry about aligning with the exists JENA-657. i.e. let's not
get stuck in details and look to the overall goals and direction.
Details come later.
Andy
[*] And there was I hoping that this was an answer to a JIRA before it
came in.
