- From: Axel Polleres <axel.polleres@urjc.es>
- Date: Mon, 04 Dec 2006 14:05:49 +0100
- To: Bijan Parsia <bparsia@cs.man.ac.uk>, public-rdf-dawg@w3.org, public-rdf-dawg-comments@w3.org
(maybe we shouldn't parallel discuss this on both dawg-comments and dawg, so let me know which list is the proper one.) Bijan Parsia wrote: > Background view: I think this is great stuff, but I suspect the group > is swamped enough without trying to take on this additional chunk of > work. It does suggest that a SPARQL/Next, or SPARQL/Extensions is worth > a continuance. > > I hate making this argument, because, esp. when a group has gone this > long, there is little energy or will to do the "next" bit. And "easy > wins" aren't necessarily so easy to get to spec, as I have to remind > myself over and over again. Pitty, if so, as I tried to stress, I restricted myself to simple extensions which IMO are useful/needed. Let's see... > On Dec 4, 2006, at 8:39 AM, Axel Polleres wrote: >> Fred Zemke wrote: >> >>> Axel Polleres wrote: >>> >>>> * I'd like to suggest to the working group some straightforward >>>> extensions of SPARQL such as adding the set difference operator >>>> MINUS, and allowing nesting of ASK queries in FILTER expressions >>>> which come basically for free in the approach. >>>> >>>> * Finally, I discuss an extension towards recursion by allowing >>>> bNode-free-CONSTRUCT queries as part of the query dataset, which >>>> may be viewed as a light-weight, recursive rule language on top of >>>> of RDF. > > > I think that'd be valuable, but seems baliwickwise, more of a RIF thing > (though I don't exactly see how they could do it). I am frankly unsure, whether RIF sees this in its scope, I rather doubt it. >>> I think the ASK and CONSTRUCT ideas are very natural. I proposed >>> them when I first took a look at SPARQL, >>> though my starting point was experience within SQL. >> >> yes, I mention explicitly that these are "easy wins" in my opinion. >> >>> SQL experience shows it is useful to be able to write subqueries. >>> In SPARQL, two natural places to put subqueries are ASK inside of >>> FILTER >>> and CONSTRUCT inside of FROM. >> >> >>> However, I don't follow you when you call CONSTRUCT inside of FROM >>> "recursive". I don't see a way, for example, to construct triples >>> with a verb >>> "is_ancestor_of" from a graph containing the verb "is_parent_of", >>> unless you have a priori information about the maximum number of >>> generations in the graph. >> >> >> I am not talking about nesting CONSTRUCT as you do (which by the way >> is another interesting idea, but, as you correctly point out, does >> not involve recursion. What I mean here is that CONSTRUCT queries >> should be allowed *as part of the dataset*. >> >> I.e., the dataset is a set of RDF graphs *plus* views which define >> implicit triples within these graphs. > > > People are sort of doing this at the protocol level. Interesting, can you explain this more concretely? >> (in the spirit of views in SQL). Since these views can recursively >> refer to the same dataset in the FROM clause, you have an implicitly >> recursive view definition. > > [snip] > >> clearly, the CONSTRUCT as part of the dataset is recursively >> referring to the same dataset, so the semantics should be the >> transitive closure in my opinion. > > That does seem reasonable and natural, if a bit tricky syntactically. > If I may make a point I've generally argued *against*....there is > nothing in SPARQL that forbids you from constructing graphs to be > queried in this way. > > Of course, that's not satisfactory in a number of ways. OTOH, do you > want to have *inline* recursively queried CONSTRUCTs? I.e., a change to > the syntax? If not, I think that defining a little rules language using > SPARQL and RDF is great, but perhaps doesn't need to be *in* SPARQL. No, I see this as a a combination of SPARQL and TURTLE. Small semantic differences like the different "PREFIX" and "@PREFIX" keyword should be easy to solve. You could view this that you define data including views or the other way around that you define a query along with some additional data... > The pieces are sort of obvioius...you want a document format that can > include both RDF data and construct queries. You could use Turtle for > the RDF and regular SPARQL for the queries. The queries could be > restricted to be CONSTRUCTs and could implicitly query (and add to) the > current document. precisely. > I think RIF can do such a thing. Doesn't seem to step on anyone's toes. As I said, I am unsure whether RIF sees such a syntax in its scope, I doubt, currently, and saw it rather possible in DAWG. I assume the resulting RIF "syntax" more involved for such combinded data+rules bases. Assumed neither in the scope of RIF nor in the scope of DAWG, could you think of any other forum to devise such an extension/combination of TURTLE+SPARQL properly? > More complex scenarios are possible where the constructs are pulling in > from other documents and "dumping" into the current context. Sounds > like good fun. Yes, this was my idea with the "implicit" metadata use case in RIF. >> Advantages of allowing such implicit definition >> of metadata within RDF are e.g. explained in RIF use case 10, see >> http://www.w3.org/TR/rif-ucr/ #Publishing_Rules_for_Interlinked_Metadata >> >> and what I wanted to achieve was using SPARQL CONSTRUCT as one >> possible syntax for this. >> >> Hope this clarifies matters. >> Note I suggest here to only allow bNode-free CONSTRUCTs, >> within graphs since otherwise you won't reach a fixpoint >> when evaluating this query! > > Is this necessarily true? I mean, it's definitely the case that if you > are naive you'll run into trouble, but that seems surmountable. For > example, you could require the constructed triples in any round of > evaluation produce a non-equivalent graph. Is there a case where > something like this wouldn't ensure termination in the RDF case? > > (You have to either go with BNodes as existentials and use > equivalence/minimization, or you have to be very strict in the > distinction between source nodes and construct generated nodes.) Hmm, I think only if bNodes are not involved in recursion, honestly... I am not sure whether I get you here, bu at the very least, you'd run into troubles if recursion over MINUS (or, to stay with existing constructs with OPTIONAL+BOUND), i.e. possible non-mon... depends maybe on the semantics which you can apply for negation and is thus an open issue which needs more research. I chose the bNode-free restriction to stay within safe grounds. best, axel -- Dr. Axel Polleres email: axel@polleres.net url: http://www.polleres.net/
Received on Monday, 4 December 2006 13:11:14 UTC