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
