Hi Alessandro, as a follow-up: I have tried to describe (briefly) the approach to extend LDPath in this article for ICLP (International Conference for Logic Programming):
http://www.schaffert.eu/wp-content/uploads/downloads/2012/07/invited-talk-ICLP-2012.pdf Greetings, Sebastian Am Donnerstag, den 21.11.2013, 10:57 +0100 schrieb Sebastian Schaffert: > Hi Alessandro, > > > Am Mittwoch, den 20.11.2013, 10:24 +0000 schrieb Alessandro Benedetti: > > Hi Sebastian, > > only to have some clarification : > > > > > > 2013/11/19 Sebastian Schaffert <[email protected]> > > > > > Hi Alessandro, > > > > > > this is a change we have in mind already for a long time, but we need to > > > be careful about the implications because it transforms LDPath into a > > > tree matching language > > > > > > Are you referring to the fact that from a language that returns a single > > node ( or set of nodes) we are transforming LDPath in a language that > > returns a sub-tree ( or a set of sub-trees ) ? > > > > > > > > with all consequences (essentially this is then a > > > unification problem with variable binding). > > > > > > Reflecting on this, in the example syntax proposed, after selected the > > parent node ( with the LDPath expression before the parenthes { ), we have > > simply to apply the relative path for each variable, to bind the variable > > with the value. > > > > Practically we already have the binding for the variables, we have only to > > follow the path and execute the substitution. > > Is it still a unification problem ? Probably yes, but it's simplified > > correct ? > > > > > The main problem is that once you introduce several variables your > simple selection problem turns into a unification problem. Without > in-depth research and just quickly writing together, this has the > following consequences: > > 1. if the same variable occurs multiple times in a pattern, you have to > make sure that all bindings are the same - similar to a join in > databases (powerful but introduces much higher complexity and > backtracking) > > Example: "select all pairs of employees with the same birthdate" > > hasEmployee { > employee { name: N1, birthday: B }, > employee { name: N2, birthday: B } > } > > (I am using more or less the syntax I used in my PhD thesis) > > This is a very cool feature, but it needs to be designed carefully > > > 2. if you have multiple variables, in your result you will also have to > produce all combinations of results, which can potentially result in a > combinatorial explosion (where you can argue that this is anyways what > the user wanted if he asked a query like this) > > Example: "select all 3-combinations of employee names" > > hasEmployee { > employee { name: N1 }, > employee { name: N2 }, > employee { name: N2 } > } > > This will (possibly by accident) build you the cross-product of all > employee names and yield a terrible number of results ;-) > > 3. what I have at the moment no idea is to what extent this will have > problems in combination with Linked Data Caching - this works well with > real path selections because they are "forward-only", but I am not sure > with tree selections, because they might require backtracking. > > > > > > > > > > Actually my PhD 10 years ago > > > was exactly on that issue (we called it "simulation unification" then, > > > referring to the two algorithms we used as a foundation - graph > > > simulation and term unification)... ;-) > > > > > > > More details regarding this part ? > > http://edoc.ub.uni-muenchen.de/2914/ - Chapter 2.6 and 8.2 ;-) > > > Greetings, > > Sebastian > >
