You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Paul Houle <pa...@ontology2.com> on 2016/07/13 17:24:47 UTC
Extended calling conventions for arithmetic functions in Jena Rules
In the following docs:
https://jena.apache.org/documentation/inference/
The arithmetic builtins are described as such:
"Note that these do not run backwards, if in sum a and c are bound and b
is unbound then the test will fail rather than bind b to (c-a). This
could be fixed."
This is repeated in the source code for said functions.
https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/builtins/Sum.java
in that case at line 78.
My question is: is the only reason this does not work because the
Builtin doesn't handle it, or because the engine wouldn't be able to
work correctly if the Builtin was fixed?
--
Paul Houle
paul.houle@ontology2.com
Re: Extended calling conventions for arithmetic functions in Jena Rules
Posted by Paul Houle <pa...@ontology2.com>.
Well if there is not interest in doing it I'd suggest removing the
suggestions that it could be done from the places where it is mentioned
in the documentation.
--
Paul Houle
paul.houle@ontology2.com
On Thu, Jul 14, 2016, at 11:17 AM, Dave Reynolds wrote:
> On 14/07/16 15:44, Paul Houle wrote:
> > If I understand that right, you're saying that the signature for
> > builtins would have to change because there would have to be some way to
> > either pass back a list of possible bindings or maybe pass back one
> > binding and an indication that there might be more, right?
>
> Right. Though just changing the signature isn't enough of course, you
> would need a non-trivial change to the backward reasoner to handle this.
>
> If this was a pure backward rule engine then the builtins would have
> support for either multiple results or for explicit backtracking (e.g.
> something like the prolog 4-port model). Historically we started with a
> forward engine and builtins were designed for that, then the system was
> extended to add backward and hybrid rules but for backward compatibility
> and simplicity we stuck with the limited notion of builtins as just
> filters not as generators of alternative solutions.
>
> > A specific multi-binding case I have thought of is a function like
> > "lcfirst" in PHP which lowercases the first character in a string. If
> > you write
> >
> > lcfirst(A,"night")
> >
> > there are two solutions for A, "night" and "Night" and it would be
> > reasonable to search backwards. On the other hand, if you are
> > lowercasing everything
> >
> > lc(A,"night")
> >
> > then you have 32 solutions when the right parameter has no uppercase
> > letters, generally 2^N solutions where N is the number of lowercase
> > letters. It is more reasonable to do the search in the other direction
> > (look up all A and see if they match) although the perfect system would
> > probably search A over a small set of prefixes and then filter.
>
> Sure and then you have cases like relational operators where the results
> can be infinite (?x > 0 etc).
>
> That sort of thing is possible in constraint logic programming where the
> equational literals act as constraints rather than generators or
> filters. Then you have a constraint engine can checks whether the
> current set of constraints is satisfiable. That's a whole different world
> :)
>
> > Even add() might have problems because of numeric coercion (there might
> > be more than one type which fits.)
>
> > Would the ability to return binding sets affect both the forward and
> > backwards modes?
>
> It's not clear what such builtins would mean in the forward world.
>
> For existing builtins like add it's easy - they are all functions so
> they don't get invoked until all the inputs are bound and then generate
> only one answer.
>
> If you allowed the current builtins to have other binding patterns with
> non-deterministic answers and/or allowed builtins to generate multiple
> results then I'm not sure what that would mean. I guess you would expect
> the forward rule to fire and generate all the possible answers.
>
> Dave
>
> > -- Paul Houle paul.houle@ontology2.com On Thu, Jul 14, 2016, at 03:57
> > AM, Dave Reynolds wrote:
> >> > 13/07/16 18:24, Paul Houle wrote:
> >>> > >In the following docs:
> >>> > >
> >>> > >https://jena.apache.org/documentation/inference/
> >>> > >
> >>> > >The arithmetic builtins are described as such:
> >>> > >
> >>> > >"Note that these do not run backwards, if in sum a and c are bound and b
> >>> > >is unbound then the test will fail rather than bind b to (c-a). This
> >>> > >could be fixed."
> >>> > >
> >>> > >This is repeated in the source code for said functions.
> >>> > >
> >>> > >https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/builtins/Sum.java
> >>> > >
> >>> > >in that case at line 78.
> >>> > >
> >>> > >My question is: is the only reason this does not work because the
> >>> > >Builtin doesn't handle it, or because the engine wouldn't be able to
> >>> > >work correctly if the Builtin was fixed?
> >> >
> >> >If I remember correctly the engine requires a deterministic answer from
> >> >the builtin - it doesn't support builtins that expand the search space
> >> >(doesn't support return of a set of legal answers). So specific cases
> >> >where there's only one unbound to an arithmetic builtin and only one
> >> >result to bind could be supported. However, in general once you allow
> >> >arithmetic expressions to run backwards you are getting into equational
> >> >constraint solve territory.
> >> >
> >> >Dave
Re: Extended calling conventions for arithmetic functions in Jena
Rules
Posted by Dave Reynolds <da...@gmail.com>.
On 14/07/16 15:44, Paul Houle wrote:
> If I understand that right, you're saying that the signature for
> builtins would have to change because there would have to be some way to
> either pass back a list of possible bindings or maybe pass back one
> binding and an indication that there might be more, right?
Right. Though just changing the signature isn't enough of course, you
would need a non-trivial change to the backward reasoner to handle this.
If this was a pure backward rule engine then the builtins would have
support for either multiple results or for explicit backtracking (e.g.
something like the prolog 4-port model). Historically we started with a
forward engine and builtins were designed for that, then the system was
extended to add backward and hybrid rules but for backward compatibility
and simplicity we stuck with the limited notion of builtins as just
filters not as generators of alternative solutions.
> A specific multi-binding case I have thought of is a function like
> "lcfirst" in PHP which lowercases the first character in a string. If
> you write
>
> lcfirst(A,"night")
>
> there are two solutions for A, "night" and "Night" and it would be
> reasonable to search backwards. On the other hand, if you are
> lowercasing everything
>
> lc(A,"night")
>
> then you have 32 solutions when the right parameter has no uppercase
> letters, generally 2^N solutions where N is the number of lowercase
> letters. It is more reasonable to do the search in the other direction
> (look up all A and see if they match) although the perfect system would
> probably search A over a small set of prefixes and then filter.
Sure and then you have cases like relational operators where the results
can be infinite (?x > 0 etc).
That sort of thing is possible in constraint logic programming where the
equational literals act as constraints rather than generators or
filters. Then you have a constraint engine can checks whether the
current set of constraints is satisfiable. That's a whole different world :)
> Even add() might have problems because of numeric coercion (there might
> be more than one type which fits.)
> Would the ability to return binding sets affect both the forward and
> backwards modes?
It's not clear what such builtins would mean in the forward world.
For existing builtins like add it's easy - they are all functions so
they don't get invoked until all the inputs are bound and then generate
only one answer.
If you allowed the current builtins to have other binding patterns with
non-deterministic answers and/or allowed builtins to generate multiple
results then I'm not sure what that would mean. I guess you would expect
the forward rule to fire and generate all the possible answers.
Dave
> -- Paul Houle paul.houle@ontology2.com On Thu, Jul 14, 2016, at 03:57
> AM, Dave Reynolds wrote:
>> > 13/07/16 18:24, Paul Houle wrote:
>>> > >In the following docs:
>>> > >
>>> > >https://jena.apache.org/documentation/inference/
>>> > >
>>> > >The arithmetic builtins are described as such:
>>> > >
>>> > >"Note that these do not run backwards, if in sum a and c are bound and b
>>> > >is unbound then the test will fail rather than bind b to (c-a). This
>>> > >could be fixed."
>>> > >
>>> > >This is repeated in the source code for said functions.
>>> > >
>>> > >https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/builtins/Sum.java
>>> > >
>>> > >in that case at line 78.
>>> > >
>>> > >My question is: is the only reason this does not work because the
>>> > >Builtin doesn't handle it, or because the engine wouldn't be able to
>>> > >work correctly if the Builtin was fixed?
>> >
>> >If I remember correctly the engine requires a deterministic answer from
>> >the builtin - it doesn't support builtins that expand the search space
>> >(doesn't support return of a set of legal answers). So specific cases
>> >where there's only one unbound to an arithmetic builtin and only one
>> >result to bind could be supported. However, in general once you allow
>> >arithmetic expressions to run backwards you are getting into equational
>> >constraint solve territory.
>> >
>> >Dave
Re: Extended calling conventions for arithmetic functions in Jena Rules
Posted by Paul Houle <pa...@ontology2.com>.
If I understand that right, you're saying that the signature for
builtins would have to change because there would have to be some way to
either pass back a list of possible bindings or maybe pass back one
binding and an indication that there might be more, right?
A specific multi-binding case I have thought of is a function like
"lcfirst" in PHP which lowercases the first character in a string. If
you write
lcfirst(A,"night")
there are two solutions for A, "night" and "Night" and it would be
reasonable to search backwards. On the other hand, if you are
lowercasing everything
lc(A,"night")
then you have 32 solutions when the right parameter has no uppercase
letters, generally 2^N solutions where N is the number of lowercase
letters. It is more reasonable to do the search in the other direction
(look up all A and see if they match) although the perfect system would
probably search A over a small set of prefixes and then filter.
Even add() might have problems because of numeric coercion (there might
be more than one type which fits.)
Would the ability to return binding sets affect both the forward and
backwards modes?
--
Paul Houle
paul.houle@ontology2.com
On Thu, Jul 14, 2016, at 03:57 AM, Dave Reynolds wrote:
> 13/07/16 18:24, Paul Houle wrote:
> > In the following docs:
> >
> > https://jena.apache.org/documentation/inference/
> >
> > The arithmetic builtins are described as such:
> >
> > "Note that these do not run backwards, if in sum a and c are bound and b
> > is unbound then the test will fail rather than bind b to (c-a). This
> > could be fixed."
> >
> > This is repeated in the source code for said functions.
> >
> > https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/builtins/Sum.java
> >
> > in that case at line 78.
> >
> > My question is: is the only reason this does not work because the
> > Builtin doesn't handle it, or because the engine wouldn't be able to
> > work correctly if the Builtin was fixed?
>
> If I remember correctly the engine requires a deterministic answer from
> the builtin - it doesn't support builtins that expand the search space
> (doesn't support return of a set of legal answers). So specific cases
> where there's only one unbound to an arithmetic builtin and only one
> result to bind could be supported. However, in general once you allow
> arithmetic expressions to run backwards you are getting into equational
> constraint solve territory.
>
> Dave
Re: Extended calling conventions for arithmetic functions in Jena
Rules
Posted by Dave Reynolds <da...@gmail.com>.
13/07/16 18:24, Paul Houle wrote:
> In the following docs:
>
> https://jena.apache.org/documentation/inference/
>
> The arithmetic builtins are described as such:
>
> "Note that these do not run backwards, if in sum a and c are bound and b
> is unbound then the test will fail rather than bind b to (c-a). This
> could be fixed."
>
> This is repeated in the source code for said functions.
>
> https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/builtins/Sum.java
>
> in that case at line 78.
>
> My question is: is the only reason this does not work because the
> Builtin doesn't handle it, or because the engine wouldn't be able to
> work correctly if the Builtin was fixed?
If I remember correctly the engine requires a deterministic answer from
the builtin - it doesn't support builtins that expand the search space
(doesn't support return of a set of legal answers). So specific cases
where there's only one unbound to an arithmetic builtin and only one
result to bind could be supported. However, in general once you allow
arithmetic expressions to run backwards you are getting into equational
constraint solve territory.
Dave