You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marmotta.apache.org by Alessandro Benedetti <be...@gmail.com> on 2013/11/19 10:39:15 UTC
Fwd: LDPath API Improvement
Hi guys,
following a discussion related to Apache Stanbol, I want to propose a new
feature in LDPath query language, to obtain nested queries and nested
objects extracting properties from a specific resource.
An example of syntax can be :
city= ../foaf:based_near { name=gn:name, population=gn:population, state=
gn:state }
Accessing to a RDF resource and then, for each resource satisfying the
parent expression, retrieve an object.
The Object properties should be the ones listed in the provided map, with
the specific aliases.
In the previous example , for example having these three resources that
satisfy the first expression ( city= ../foaf:based_near ) , we want to
retrieve these 3 objects of type city ( the population numbers are fancy
number):
city1{ name= Paris, population= 13.000.000, state=France}
city2{ name= Rome, population= 6.000.000, state=Italy}
city3{ name= London, population= 16.000.000, state=England}
The scope of this improvement is to provide the possibility of extract
array of objects with custom properties from the resources of our data set.
--
--------------------------
Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti
"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"
William Blake - Songs of Experience -1794 England
--
--------------------------
Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti
"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"
William Blake - Songs of Experience -1794 England
Re: Fwd: LDPath API Improvement
Posted by Sebastian Schaffert <ss...@apache.org>.
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 <ss...@apache.org>
> >
> > > 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
>
>
Re: Fwd: LDPath API Improvement
Posted by Sebastian Schaffert <ss...@apache.org>.
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 <ss...@apache.org>
>
> > 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
Re: Fwd: LDPath API Improvement
Posted by Alessandro Benedetti <be...@gmail.com>.
Hi Sebastian,
only to have some clarification :
2013/11/19 Sebastian Schaffert <ss...@apache.org>
> 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 ?
> 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 ?
>
> I'll still think about it a bit, but I think there is a clear
> opportunity for a good improvement here.
>
> Greetings,
>
Cheers
>
> Sebastian
>
> Am Dienstag, den 19.11.2013, 09:39 +0000 schrieb Alessandro Benedetti:
> > Hi guys,
> > following a discussion related to Apache Stanbol, I want to propose a new
> > feature in LDPath query language, to obtain nested queries and nested
> > objects extracting properties from a specific resource.
> >
> > An example of syntax can be :
> >
> > city= ../foaf:based_near { name=gn:name, population=gn:population, state=
> > gn:state }
> >
> > Accessing to a RDF resource and then, for each resource satisfying the
> > parent expression, retrieve an object.
> > The Object properties should be the ones listed in the provided map, with
> > the specific aliases.
> >
> > In the previous example , for example having these three resources that
> > satisfy the first expression ( city= ../foaf:based_near ) , we want to
> > retrieve these 3 objects of type city ( the population numbers are fancy
> > number):
> >
> > city1{ name= Paris, population= 13.000.000, state=France}
> > city2{ name= Rome, population= 6.000.000, state=Italy}
> > city3{ name= London, population= 16.000.000, state=England}
> >
> > The scope of this improvement is to provide the possibility of extract
> > array of objects with custom properties from the resources of our data
> set.
> >
> > --
> > --------------------------
> >
> > Benedetti Alessandro
> > Visiting card : http://about.me/alessandro_benedetti
> >
> > "Tyger, tyger burning bright
> > In the forests of the night,
> > What immortal hand or eye
> > Could frame thy fearful symmetry?"
> >
> > William Blake - Songs of Experience -1794 England
> >
> >
> >
>
>
>
--
--------------------------
Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti
"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"
William Blake - Songs of Experience -1794 England
Re: Fwd: LDPath API Improvement
Posted by Sebastian Schaffert <ss...@apache.org>.
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 with all consequences (essentially this is then a
unification problem with variable binding). 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)... ;-)
I'll still think about it a bit, but I think there is a clear
opportunity for a good improvement here.
Greetings,
Sebastian
Am Dienstag, den 19.11.2013, 09:39 +0000 schrieb Alessandro Benedetti:
> Hi guys,
> following a discussion related to Apache Stanbol, I want to propose a new
> feature in LDPath query language, to obtain nested queries and nested
> objects extracting properties from a specific resource.
>
> An example of syntax can be :
>
> city= ../foaf:based_near { name=gn:name, population=gn:population, state=
> gn:state }
>
> Accessing to a RDF resource and then, for each resource satisfying the
> parent expression, retrieve an object.
> The Object properties should be the ones listed in the provided map, with
> the specific aliases.
>
> In the previous example , for example having these three resources that
> satisfy the first expression ( city= ../foaf:based_near ) , we want to
> retrieve these 3 objects of type city ( the population numbers are fancy
> number):
>
> city1{ name= Paris, population= 13.000.000, state=France}
> city2{ name= Rome, population= 6.000.000, state=Italy}
> city3{ name= London, population= 16.000.000, state=England}
>
> The scope of this improvement is to provide the possibility of extract
> array of objects with custom properties from the resources of our data set.
>
> --
> --------------------------
>
> Benedetti Alessandro
> Visiting card : http://about.me/alessandro_benedetti
>
> "Tyger, tyger burning bright
> In the forests of the night,
> What immortal hand or eye
> Could frame thy fearful symmetry?"
>
> William Blake - Songs of Experience -1794 England
>
>
>