That's very interesting Martynas and I will keep this option in mind. I'm not sure it applies to what I want to do, as I do not want just a syntactic query translation, but also tweaking the query engine and getting results by executing it.
Dimitris On Fri, Jun 22, 2012 at 9:24 PM, Martynas Jusevičius <[email protected]> wrote: > It might not be the traditional solution, but I've done some SPARQL query > transformations with RDF/XML and XSLT 2. > > It doesn't work on the algebra level, but rather on the SPIN serialization. > It might or might not be easier than Java code. I don't know if that > applies in your case. > > Martynad > graphity.org > On Jun 22, 2012 6:10 PM, "Paul Gearon" <[email protected]> wrote: > >> On Fri, Jun 22, 2012 at 9:30 AM, Dimitris Spanos <[email protected]> >> wrote: >> > Hello all, >> > >> > I'm trying to traverse and process the algebra expression tree for a >> > SPARQL query. For this purpose, I have created a class that implements >> > OpVisitor and visits the entire tree in a top-down fashion. Ideally, I >> > would like to be able to pass information from a visited operator to >> > its children and vice versa, but I'm not sure how I can do this in an >> > elegant way (using just some global class variables does not seem >> > sufficient). >> >> From parents to children and back up again is reasonably >> straightforward. Just have the visitor keep a stack of where it's >> visited (so the visitor knows about the parent to the current Op), and >> accumulate results as it finishes processing an Op (so the visitor has >> information about what the processing of child Ops returned). >> >> > I guess a naive way to deal with it would be to start from the top of >> > the tree, visit every Op, transform it to a custom extension of the >> > respective Op that will maybe hold a link to the parent (already >> > transformed) Op and store the information that will get passed to its >> > children. At the same time, every such transformed Op will be inserted >> > into a Stack and, after the top-down traversal is done, popped out in >> > reverse order in order to go back up the tree and pass information >> > from children Ops to parent Ops. >> >> I think that what you're describing here is a transformation of the >> tree into another tree. That works, but it's more than what you said >> in the first paragraph (where you just need to have results of >> processing children, plus knowledge of what your parents are). >> >> Personally, I prefer to update the nodes in my trees so that they can >> be transformed directly, rather than being mapped to an equivalent >> tree before transforming. However, in the case of Op I can appreciate >> why you may not want to touch the existing structure. >> >> If you just need the info of where you are in the tree as you process >> it, then I recommend just keeping a stack in the tree walker that you >> use. If you need to see "across the tree" as you're processing, then >> mapping the tree to an equivalent that is more amenable to processing >> (as you suggest) is preferable to modifying Op. >> >> > Is there another more straightforward procedure to accomplish this? >> >> For this kind of processing, I really, *really* prefer using Clojure >> (using protocols to extend Op would make this a breeze). However, I >> don't see that getting inserted into the Jena dependencies any time >> soon. ;-) >> >> > Sorry for sounding completely abstract, I hope I'm making (some) >> > sense, any ideas/hints/pointers to examples would be very much >> > appreciated! >> >> That's OK. I sometimes find that the large amounts of boilerplate that >> Java requires for things like the visitor pattern can get in the way >> of seeing exactly how to accomplish something. >> >> Paul >>
