Bug matching relex2logic rule constant

[williampma]

The checkRuleApplicability method in LogicProcessor.java apparently cannot match constant if it's defined at the first part of the logic. For example, the sentence "I ate all cookies." produce

Matching rule 'ALLRULE1'...
Matching criterium: _quantity($noun, all)...
Found node '_quantity'
Its 'name' is '<< all >>'
I just recorded the value of 'all' to be 'all'
I just recorded the value of '$noun' to be 'cookie'
All criteria for rule 'ALLRULE1' satisfied, scheme output: ("all"-rule "cookie" (get-instance-name "cookie" "cookies@a8a3e64e-846e-40d3-bd86-57d56852a1f0" sentence_index))

where the constant "all" is treated as variable. If the constant is defined as the 2nd part of the logic as in the TENSEPOS rule, it is fine.

Matching rule 'TENSEPOS'...
Matching criterium: tense($W, $Tense)...
Found node 'tense'
It is valued, the value is 'past'
Found node 'tense'
Its 'name' is '<< past >>'
I just recorded the value of '$Tense' to be 'past'
I just recorded the value of '$W' to be 'eat'
Matching criterium: pos($W, verb)...
Found node 'pos'
It is valued, the value is 'verb'
This value matches the one specified in the rule!
Found node 'pos'
It is valued, the value is 'noun'
Found node 'pos'
It is valued, the value is 'adj'
Found node 'pos'
It is valued, the value is 'noun'
Found node 'pos'
It is valued, the value is 'punctuation'
Found node 'pos'
It is valued, the value is 'noun'
All criteria for rule 'TENSEPOS' satisfied, scheme output: (tense-rule "eat" (get-instance-name "eat" "ate@3b8bdc4e-86b6-4c06-bb3f-b6722a496cc1" sentence_index) "past")

[rodsol]

'all' can't be defined as a variable like the 2nd part in TENSEPOS rule.
all-rule is defined for quantifier 'all'. all-rule need _quantity($noun, all) as a criteria to be applied.
where $noun → is any noun
all → is the quantifier 'all'
eg - _quantity(book, all) ,_quantity(cookie, all) …

In LogicProcessor the checkRuleApplicability function create variables secondVariableName and secondVariableValue

then it set the name of the node to variable secondVariableValue and the second part of the criteria to variable secondVariableName .. for later use
in this case both value is 'all'

I think it prints "I just recorded the value of 'all' to be 'all'" for debugging purpose

[linas]

is there a fix forthcoming?

[williampma]

Just to make it more clear (instead of seeing "all" everywhere), here's the result of "some", which also has _quantity:

Matching rule 'ALLRULE1'...
Matching criterium: _quantity($noun, all)...
Found node '_quantity'
Its 'name' is '<< some >>'
I just recorded the value of 'all' to be 'some'
I just recorded the value of '$noun' to be 'cookie'
All criteria for rule 'ALLRULE1' satisfied, scheme output: ("some"-rule "cookie" (get-instance-name "cookie" "cookies@3e47d381-3edf-4fda-a895-918802d620f8" sentence_index))

"all" is treated as a variable instead of constant and get replaced as "some". The foundNode.isValued() check is somehow returning false, instead of true.

[williampma]

For the sentence "John is a boy.", the gender-rule is failing too:

Matching rule 'GENDER'...
Matching criterium: person-FLAG($W, T)...
Found node 'person-FLAG'
It is valued, the value is 'T'
This value matches the one specified in the rule!
Matching criterium: gender($W, $gender)...
Found node 'gender'
It is valued, the value is 'masculine'
Not all criteria for rule 'GENDER' satisfied :(

It looks like a problem with determining what is valued and what is not? Right now it looks like Dependency relations (those with underscores like _obj and _subj) are always non-valued, while Attributes (those without underscores) is usually valued with some exception (like tense). It looks like the bug is happening much earlier than Relex2Logic. Perhaps this is related to issue #26

[williampma]

Actually, why would we even use whether a FeatureNode is valued or not as a prerequisite for whether to treat a variable in ruleCriterium as a constant? Shouldn't we first check whether ruleCriterium.getSecondVariableName() is a constant (with or without the $ sign). If it is a constant, we try to match with foundNode.getValue() or foundNode.get("name").getValue().

Right now it looks like defining a rule with _quantity($a, $b), _quantity($a, b), _quantity(+a, +b), etc, will all be treated the same, since the $ sign isn't checked.

[ruiting]

Hi William,

I agree with you. The $ sign should be checked to distinguish the variables from the constants...

It seems to me that the failing of matching GENDER rule is also caused by not dealing with $ well enough, as $gender is not a constant, it should be matched while applying the GENDER rule. The value of the $gender will be replace in the helper function.

---

(define (gender-rule word word_instance gender_type)
(define concept_node (ConceptNode word))
(InheritanceLink (SpecificEntityNode word_instance) (ConceptNode word))
(InheritanceLink (SpecificEntityNode word_instance) (ConceptNode "person"))
(cond ((string=? gender_type "feminine")
(InheritanceLink (SpecificEntityNode word_instance) (ConceptNode "woman"))
)
((string=? gender_type "masculine")
(InheritanceLink (SpecificEntityNode word_instance) (ConceptNode "man"))
)
)
)

---

If I understand correctly that what you meant by "what is valued" is about the constant and variable problems as well. So the constants should be valued, and the variables shouldn't be valued... I think it's correct that _obj, _subj etc dependency relations are non-valued because they are variables instead of constants... _subj($x, $y), _obj($x, $z).. However, I don't understand while the tense is usually valued.

[ruiting]

Sorry, it seems that I misunderstood about the "what is valued" problem... I think the point of detecting if the FeatureNode is valued or not is to traverse the whole FeatureStructure to check what kind of rules can be applied for each FeatureNode, not for treating a variable in ruleCriterium

[linas]

This issue is being discussed in a distinct email thread. Some excerpts:

I said:
"if I remember correctly, isValued() is true if the node holds an actual value (i.e. a string). Otherwise, that node is a map (a collection of key-value-pairs) ind its value is 'undefined'. The problem, as originally described, just sounded like too many quotation marks were being printed. I guess its more than just that?"

William replied:
"The original quotation problem is a result of the method not distinguishing variables and constants in the rule definition, and it is using isValued to determine whether to treat something as a constant."

I plan to reply: "relex does not know what a variable or a constant is; it does not have these concepts. Certainly, isValued() will not tell them apart, whatever these concepts may be." really -- I have no idea .. what is a 'variable' and what is a 'constant' ???

[linas]

William Ma then states:
"In addition, the algorithm used for matching rule and FeatureNode is a bit strange at the moment. Let's say we have a multi-conditional rule C1($x, $y) & $C2($y, $z). Right now, when checkRuleApplicability found a node of the same name as C1 in the Feature Structure, instead of checking whether C2 with matching values exists in the Feature Structure, the method will keep going matching C1 against the rest of the FeatureStructure. So if there are multiple C1 in the Feature Structure, it will just keep the last one, then go on and do the same with C2 by again finding the last one in the Feature Structure. It does not try to see if the values match with C1 either, if C2's isValued happened to be false.

Unless I completely misunderstood the expected result of Relex2Logic, right now multiple-conditional (and rules with constant) only seems to work randomly if one of the condition happens to be isValued? For single-conditional rules the method might be OK."

[linas]

Ah, so then variables are a concept untroduced by the relex2logic pattern matcher... makes sense.

[linas]

(Github is mangling the comments below. Hit the pencil icon in upper right to view them.)

Hi All,

On 8 May 2014 23:03, William Ma [email protected] wrote:

The original quotation problem is a result of the method not
distinguishing variables and constants in the rule definition, and it is
using isValued to determine whether to treat something as a constant.

OK, that's just bizarre, that's some kind of bug. Relex itself does not have a concept of 'variable' and 'constant'; they're indistinguishable.

From what I can tell, relex2logic introduces a new kind of pattern matcher,
which does use variable/constant concepts. ... based on what you say
below, this pattern matcher appears to be buggy. Which is the problem with
always inventng new pattern matchers, over and over: they seem simple at
first, but they never are, in the end, since they always grow and expand to
have to deal with ever-more complex situations. :-(

If the below is really the issue, then the relex2logic pattern matcher will
have to be extended to deal with checkpointing and back-tracking. This
requires adding a stack. Yes, that is a major design change.

Hard not to say "gee, well, I told you so" .... as I did ...

In addition, the algorithm used for matching rule and FeatureNode is a bit
strange at the moment. Let's say we have a multi-conditional rule C1($x,
$y) & $C2($y, $z). Right now, when checkRuleApplicability found a node of
the same name as C1 in the Feature Structure, instead of checking whether
C2 with matching values exists in the Feature Structure, the method will
keep going matching C1 against the rest of the FeatureStructure. So if
there are multiple C1 in the Feature Structure, it will just keep the last
one, then go on and do the same with C2 by again finding the last one in
the Feature Structure. It does not try to see if the values match with C1
either, if C2's isValued happened to be false.

Unless I completely misunderstood the expected result of Relex2Logic,
right now multiple-conditional (and rules with constant) only seems to work
randomly if one of the condition happens to be isValued? For
single-conditional rules the method might be OK.

William

On Friday, May 9, 2014 11:30:16 AM UTC+8, linas wrote:

Hi William,

Its been a while but if I remember correctly, isValued() is true if the
node holds an actual value (i.e. a string). Otherwise, that node is a map
(a collection of key-value-pairs) ind its value is 'undefined'.

the problem, as originally described, just sounded like too many
quotation marks were being printed. I guess its more than just that?

--linas

On 8 May 2014 22:03, William Ma [email protected] wrote:

I agree it might be better to discuss it here since posting on github
seems to bombard people's email.

In addition to the issue you posted on opencog
opencog/opencog#722 , I also posted one on
relex #23

I suspect majority of the problems are in the checkRuleApplicability
method in LogicProcessor.java, which is not matching rules with
FeatureNodes properly. I tried to see if this is something that can be
fixed by adding a few lines of code, but now I believe it will require a
complete re-written of the method. It requires a better understanding of
the Feature Structure representation I think (http://wiki.opencog.org/w/
Sentence_algorithms). I still couldn't understand why we care if a
FeatureNode.isValued matters to which and how the rules are applied.

William

On Friday, May 9, 2014 4:14:11 AM UTC+8, Sebastian Ruder wrote:

Hi,

I don't want to open up a new issue for every error I'm experiencing as
I fear that I just missed when they were discussed. Thus I'm posting them
here in combination.

I've been parsing some sentences with RelEx in the OpenCog shell that
were meant to trigger certain RelEx2Logic rules.
However, for a some of sentences, such as
She doesn't play. He does not run. (I thought these would trigger the
negative-rule)
Maybe he is right. (Supposed to trigger the maybe-rule which - I
realized - is not implemented)
I like all trees. This dog is good. (Supposed to trigger
all-rule/det-rule; mentioned in a newly created issue.)

I experienced an error with a long stacktrace ending in ERROR: In
procedure catch-closure: and some different kind of error type. Is
this "normal", i.e. can't RelEx / RelEx2Logic deal with these types of
sentences yet? If so, why not? If not, why do these sentences trigger these
errors and how should I deal with future errors?

Best,
Sebastian

--
You received this message because you are subscribed to the Google
Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].

Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

[linas]

Linas,

I don't think the needed bugfix to the RelEx2Logic rule engine will be
nearly as extensive as you're suggesting.... Ruiting and William will
figure it out on Monday though...

Re your other comments, Misgana is shortly going to make a
general-purpose rule engine using your pattern matcher, with some
guidance from Cosmo. RelEx2Logic, and possibly PLN, will then be
ported to the new C++ pattern matcher based rule engine. So please
get ready for a lot of questions and/or requests regarding the pattern
matcher during the next month (they have already started, from Cosmo,
of course ... ;)

Good night...

ben

On Fri, May 9, 2014 at 11:32 PM, Linas Vepstas [email protected] wrote:

Hi All,

On 8 May 2014 23:03, William Ma [email protected] wrote:

The original quotation problem is a result of the method not
distinguishing variables and constants in the rule definition, and it is
using isValued to determine whether to treat something as a constant.

OK, that's just bizarre, that's some kind of bug. Relex itself does not
have a concept of 'variable' and 'constant'; they're indistinguishable.

From what I can tell, relex2logic introduces a new kind of pattern matcher,
which does use variable/constant concepts. ... based on what you say
below, this pattern matcher appears to be buggy. Which is the problem with
always inventng new pattern matchers, over and over: they seem simple at
first, but they never are, in the end, since they always grow and expand to
have to deal with ever-more complex situations. :-(

If the below is really the issue, then the relex2logic pattern matcher will
have to be extended to deal with checkpointing and back-tracking. This
requires adding a stack. Yes, that is a major design change.

Hard not to say "gee, well, I told you so" .... as I did ...

In addition, the algorithm used for matching rule and FeatureNode is a bit
strange at the moment. Let's say we have a multi-conditional rule C1($x,
$y) & $C2($y, $z). Right now, when checkRuleApplicability found a node of
the same name as C1 in the Feature Structure, instead of checking whether C2
with matching values exists in the Feature Structure, the method will keep
going matching C1 against the rest of the FeatureStructure. So if there are
multiple C1 in the Feature Structure, it will just keep the last one, then
go on and do the same with C2 by again finding the last one in the Feature
Structure. It does not try to see if the values match with C1 either, if
C2's isValued happened to be false.

Unless I completely misunderstood the expected result of Relex2Logic,
right now multiple-conditional (and rules with constant) only seems to work
randomly if one of the condition happens to be isValued? For
single-conditional rules the method might be OK.

William

On Friday, May 9, 2014 11:30:16 AM UTC+8, linas wrote:

Hi William,

Its been a while but if I remember correctly, isValued() is true if the
node holds an actual value (i.e. a string). Otherwise, that node is a map
(a collection of key-value-pairs) ind its value is 'undefined'.

the problem, as originally described, just sounded like too many
quotation marks were being printed. I guess its more than just that?

--linas

On 8 May 2014 22:03, William Ma [email protected] wrote:

I agree it might be better to discuss it here since posting on github
seems to bombard people's email.

In addition to the issue you posted on opencog
opencog/opencog#722 , I also posted one on relex
#23

I suspect majority of the problems are in the checkRuleApplicability
method in LogicProcessor.java, which is not matching rules with FeatureNodes
properly. I tried to see if this is something that can be fixed by adding a
few lines of code, but now I believe it will require a complete re-written
of the method. It requires a better understanding of the Feature Structure
representation I think (http://wiki.opencog.org/w/Sentence_algorithms). I
still couldn't understand why we care if a FeatureNode.isValued matters to
which and how the rules are applied.

William

On Friday, May 9, 2014 4:14:11 AM UTC+8, Sebastian Ruder wrote:

Hi,

I don't want to open up a new issue for every error I'm experiencing as
I fear that I just missed when they were discussed. Thus I'm posting them
here in combination.

I've been parsing some sentences with RelEx in the OpenCog shell that
were meant to trigger certain RelEx2Logic rules.
However, for a some of sentences, such as
She doesn't play. He does not run. (I thought these would trigger the
negative-rule)
Maybe he is right. (Supposed to trigger the maybe-rule which - I
realized - is not implemented)
I like all trees. This dog is good. (Supposed to trigger
all-rule/det-rule; mentioned in a newly created issue.)

I experienced an error with a long stacktrace ending in ERROR: In
procedure catch-closure: and some different kind of error type. Is this
"normal", i.e. can't RelEx / RelEx2Logic deal with these types of sentences
yet? If so, why not? If not, why do these sentences trigger these errors and
how should I deal with future errors?

Best,
Sebastian

You received this message because you are subscribed to the Google
Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].

Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

Ben Goertzel, PhD
http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt.
James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free
our minds" -- Robert Nesta Marley

[linas]

I'm both thrilled and petrified.

--linas

On 9 May 2014 11:59, Ben Goertzel [email protected] wrote:

Linas,

I don't think the needed bugfix to the RelEx2Logic rule engine will be
nearly as extensive as you're suggesting.... Ruiting and William will
figure it out on Monday though...

Re your other comments, Misgana is shortly going to make a
general-purpose rule engine using your pattern matcher, with some
guidance from Cosmo. RelEx2Logic, and possibly PLN, will then be
ported to the new C++ pattern matcher based rule engine. So please
get ready for a lot of questions and/or requests regarding the pattern
matcher during the next month (they have already started, from Cosmo,
of course ... ;)

Good night...

ben

On Fri, May 9, 2014 at 11:32 PM, Linas Vepstas [email protected]
wrote:

Hi All,

On 8 May 2014 23:03, William Ma [email protected] wrote:

The original quotation problem is a result of the method not
distinguishing variables and constants in the rule definition, and it is
using isValued to determine whether to treat something as a constant.

OK, that's just bizarre, that's some kind of bug. Relex itself does not
have a concept of 'variable' and 'constant'; they're indistinguishable.

From what I can tell, relex2logic introduces a new kind of pattern
matcher,
which does use variable/constant concepts. ... based on what you say
below, this pattern matcher appears to be buggy. Which is the problem
with
always inventng new pattern matchers, over and over: they seem simple at
first, but they never are, in the end, since they always grow and expand
to
have to deal with ever-more complex situations. :-(

If the below is really the issue, then the relex2logic pattern matcher
will
have to be extended to deal with checkpointing and back-tracking. This
requires adding a stack. Yes, that is a major design change.

Hard not to say "gee, well, I told you so" .... as I did ...

In addition, the algorithm used for matching rule and FeatureNode is a
bit
strange at the moment. Let's say we have a multi-conditional rule
C1($x,
$y) & $C2($y, $z). Right now, when checkRuleApplicability found a node
of
the same name as C1 in the Feature Structure, instead of checking
whether C2
with matching values exists in the Feature Structure, the method will
keep
going matching C1 against the rest of the FeatureStructure. So if
there are
multiple C1 in the Feature Structure, it will just keep the last one,
then
go on and do the same with C2 by again finding the last one in the
Feature
Structure. It does not try to see if the values match with C1 either,
if
C2's isValued happened to be false.

Unless I completely misunderstood the expected result of Relex2Logic,
right now multiple-conditional (and rules with constant) only seems to
work
randomly if one of the condition happens to be isValued? For
single-conditional rules the method might be OK.

William

On Friday, May 9, 2014 11:30:16 AM UTC+8, linas wrote:

Hi William,

Its been a while but if I remember correctly, isValued() is true if the
node holds an actual value (i.e. a string). Otherwise, that node is a
map
(a collection of key-value-pairs) ind its value is 'undefined'.

the problem, as originally described, just sounded like too many
quotation marks were being printed. I guess its more than just that?

--linas

On 8 May 2014 22:03, William Ma [email protected] wrote:

I agree it might be better to discuss it here since posting on github
seems to bombard people's email.

In addition to the issue you posted on opencog
opencog/opencog#722 , I also posted one on
relex
#23

I suspect majority of the problems are in the checkRuleApplicability
method in LogicProcessor.java, which is not matching rules with
FeatureNodes
properly. I tried to see if this is something that can be fixed by
adding a
few lines of code, but now I believe it will require a complete
re-written
of the method. It requires a better understanding of the Feature
Structure
representation I think (http://wiki.opencog.org/w/Sentence_algorithms).
I
still couldn't understand why we care if a FeatureNode.isValued
matters to
which and how the rules are applied.

William

On Friday, May 9, 2014 4:14:11 AM UTC+8, Sebastian Ruder wrote:

Hi,

I don't want to open up a new issue for every error I'm experiencing
as
I fear that I just missed when they were discussed. Thus I'm posting
them
here in combination.

I've been parsing some sentences with RelEx in the OpenCog shell that
were meant to trigger certain RelEx2Logic rules.
However, for a some of sentences, such as
She doesn't play. He does not run. (I thought these would trigger the
negative-rule)
Maybe he is right. (Supposed to trigger the maybe-rule which - I
realized - is not implemented)
I like all trees. This dog is good. (Supposed to trigger
all-rule/det-rule; mentioned in a newly created issue.)

I experienced an error with a long stacktrace ending in ERROR: In
procedure catch-closure: and some different kind of error type. Is
this
"normal", i.e. can't RelEx / RelEx2Logic deal with these types of
sentences
yet? If so, why not? If not, why do these sentences trigger these
errors and
how should I deal with future errors?

Best,
Sebastian

You received this message because you are subscribed to the Google
Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].

Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google
Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

Ben Goertzel, PhD
http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt.
James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free
our minds" -- Robert Nesta Marley

You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

[linas]

Hi Linas,

The current RelEx2Logic rule engine code didn't introduce the constant and
variable at all, though we want to use those concepts. Thanks for the
reminds.

I checked the LogicProcessor.java code and I think the bug was just caused
by not properly traversing the FeatureStructure. I just discussed it with
William, and he is going to fix the bug. Thanks.

On Friday, May 9, 2014, Linas Vepstas [email protected] wrote:

Hi All,

On 8 May 2014 23:03, William Ma [email protected] wrote:

The original quotation problem is a result of the method not
distinguishing variables and constants in the rule definition, and it is
using isValued to determine whether to treat something as a constant.

OK, that's just bizarre, that's some kind of bug. Relex itself does not
have a concept of 'variable' and 'constant'; they're indistinguishable.

From what I can tell, relex2logic introduces a new kind of pattern
matcher, which does use variable/constant concepts. ... based on what you
say below, this pattern matcher appears to be buggy. Which is the problem
with always inventng new pattern matchers, over and over: they seem simple
at first, but they never are, in the end, since they always grow and expand
to have to deal with ever-more complex situations. :-(

If the below is really the issue, then the relex2logic pattern matcher
will have to be extended to deal with checkpointing and back-tracking. This
requires adding a stack. Yes, that is a major design change.

Hard not to say "gee, well, I told you so" .... as I did ...

In addition, the algorithm used for matching rule and FeatureNode is a bit
strange at the moment. Let's say we have a multi-conditional rule C1($x,
$y) & $C2($y, $z). Right now, when checkRuleApplicability found a node of
the same name as C1 in the Feature Structure, instead of checking whether
C2 with matching values exists in the Feature Structure, the method will
keep going matching C1 against the rest of the FeatureStructure. So if
there are multiple C1 in the Feature Structure, it will just keep the last
one, then go on and do the same with C2 by again finding the last one in
the Feature Structure. It does not try to see if the values match with C1
either, if C2's isValued happened to be false.

Unless I completely misunderstood the expected result of Relex2Logic,
right now multiple-conditional (and rules with constant) only seems to work
randomly if one of the condition happens to be isValued? For
single-conditional rules the method might be OK.

William

On Friday, May 9, 2014 11:30:16 AM UTC+8, linas wrote:

Hi William,

Its been a while but if I remember correctly, isValued() is true if the
node holds an actual value (i.e. a string). Otherwise, that node is a map
(a collection of key-value-pairs) ind its value is 'undefined'.

the problem, as originally described, just sounded like too many quotation
marks were being printed. I guess its more than just that?

--linas

On 8 May 2014 22:03, William Ma [email protected] wrote:

I agree it might be better to discuss it here since posting on github
seems to bombard people's email.

In addition to the issue you posted on opencog https://github.com/opencog/
opencog/issues/722 , I also posted one on relex
#23

I suspect majority of the problems are in the checkRuleApplicability
method in LogicProcessor.java, which is not matching rules with
FeatureNodes properly. I tried to see if this is something that can be
fixed by adding a few lines of code, but now I believe it will require a
complete re-written of the method. It requires a better understanding of
the Feature Structure representation I think (http://wiki.opencog.org/w/
Sentence_algorithms). I still couldn't understand why we care if a
FeatureNode.isValued matters to which and how the rules are applied.

William

On Friday, May 9, 2014 4:14:11 AM UTC+8, Sebastian Ruder wrote:

Hi,

I don't want to open up a new issue for every error I'm experiencing as I
fear that I just missed when they were discussed. Thus I'm posting them
here in combination.

I've been parsing some sentences with RelEx in the OpenCog shell that were
meant to trigger certain RelEx2Logic rules.
However, for a some of sentences, such as
She doesn't play. He does not run. (I thought these would trigger the
negative-rule)
Maybe he is right. (Supposed to trigger the maybe-rule which - I realized

• is not implemented)
  I like all trees. This dog is good. (Supposed to trigger
  all-rule/det-rule; mentioned in a newly created issue.)

I experienced an error with a long stacktrace ending in ERROR: In
procedure catch-closure: and some different kind of error type. Is this
"normal", i.e. can't RelEx / RelEx2Logic deal with these types of sentences
yet? If so, why not? If not, why do these sentences trigger these errors
and how should I deal with future errors?

Best,
Sebastian

--
You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

[williampma]

Apparently Amen was already working on part of the bug. I will let him finish and work on what remains, if any.

Just to clarify, in addition to the code not checking for variables and constants defined in the rule, it is also not handling multi-conditional. Right now it just happens to work for short sentence.

[sebastianruder]

I pulled the changes, but the issue doesn't seem to be resolved: For the all-rule and the sentence "All cats are green." I get an error indicating that the "all" in all-rule is now taken as a value as well?

In ice-9/eval-string.scm:
  44: 6 [read-and-eval #<input: string b5af000> #:lang ...]
  37: 5 [lp ("all" -rule "cat" ...)]

[amebel]

@sebastianruder I just run "All cats are green." on relex and got the following result.

All cats are green.

====

Parse 1 of 1
Parse confidence: 0.8693
cost vector = (UNUSED=0 DIS=0 LEN=7)

======

Dependency relations:

    _quantity(cat, all)
    _predadj(cat, green)

Attributes:

    tense(green, present)
    subscript-TAG(green, .a)
    pos(green, adj)
    subscript-TAG(cat, .n)
    pos(cat, noun)
    noun_number(cat, plural)
    subscript-TAG(all, .a)
    pos(all, adj)
    subscript-TAG(be, .v)
    pos(be, verb)
    pos(., punctuation)


======

Loaded 22 ReLex2Logic rule(s) succesfully.

======

Relex2Logic output:
(tense-rule "green" (get-instance-name "green" "green@4942ce2a-46b9-4e4d-9bac-705d453dcb1a" (ParseNode "sentence@e142618c-3e6e-4687-88c7-395f7f6c3b41_parse_0")) "present")
(SVP-rule "cat" (get-instance-name "cat" "cats@66eb11e9-3a96-4f5b-8f4f-3d2439817c66" (ParseNode "sentence@e142618c-3e6e-4687-88c7-395f7f6c3b41_parse_0")) "green" (get-instance-name "green" "green@4942ce2a-46b9-4e4d-9bac-705d453dcb1a" (ParseNode "sentence@e142618c-3e6e-4687-88c7-395f7f6c3b41_parse_0")))
(all-rule "green" (get-instance-name "green" "green@4942ce2a-46b9-4e4d-9bac-705d453dcb1a" (ParseNode "sentence@e142618c-3e6e-4687-88c7-395f7f6c3b41_parse_0")))


======

; Bye.

Would you please write out the details on how you got the error?
Thanks

[linas]

@amebel,

I don't know what Sebastian is complaining about, but, for me, the following seems very wrong:

(tense-rule "green" ... "present") 

green is not a verb, how can it have a tense ???

(all-rule "green"  ... ParseNode ...)

This seems to say that all somethings are green, but what are the somethings? the parse nodes???

[amebel]

@linas

(tense-rule "green" ... "present") 

there are two bugs in that, one relex outputs tense(green, present)
and two r2l doesn't check for the second parameter of a unary relation, taking
pos(green, adj)
as pos(green, verb) ; to be fixed today.

With regard to the interpretation of the application of all-rule on green that is a totally different bug that is being worked on.

[sebastianruder]

@amebel, I've pulled again but I unfortunately don't get the same output as you do. Can you help me? I run opencog-server.sh and do rlwrap telnet localhost 4444. For 'All cats are green', I get the following RelEx2Logic rules:

(tense-rule "green" (get-instance-name "green" "green@774248af-0474-40de-b82b-3940e6f4a5a6" (ParseNode "sentence@21345469-156d-4645-8586-32c5f91ec393_parse_0")) "present")
(SVP-rule "cat" (get-instance-name "cat" "cats@a8486b14-2f1c-4a70-8291-866d5baf7091" (ParseNode "sentence@21345469-156d-4645-8586-32c5f91ec393_parse_0")) "green" (get-instance-name "green" "green@774248af-0474-40de-b82b-3940e6f4a5a6" (ParseNode "sentence@21345469-156d-4645-8586-32c5f91ec393_parse_0")))
("all"-rule "cat" (get-instance-name "cat" "cats@a8486b14-2f1c-4a70-8291-866d5baf7091" (ParseNode "sentence@21345469-156d-4645-8586-32c5f91ec393_parse_0")))

[cosmoharrigan]

@sebastianruder to be sure, did you already run

~/relex$ install-scripts/install-ubuntu-dependencies.sh

(or run the commands manually to rebuild)
after pulling the latest version?

[sebastianruder]

@amebel, thanks for the tip! I forgot to rebuild it. All clear. Works great now! 👍

[cosmoharrigan]

thanks for the tip! I forgot to rebuild it. All clear. Works great now!

Good to hear.

[sebastianruder]

I've just parsed some sentences, but the constant (e.g. be in [BE] ... _subj(be, $x) or all in [ALLRULE1] ... _quantity($noun, all) seems still not to be recognized as a constant - at least the way I perceive it.
It seems to take any input, so that the be-inheritance-rule is applied to a sentence like "Men breathe air" or "Men eat food" and the all-rule is applied to a sentence such as "Some men eat" or "Few people play". In both of these, there is no all nor to be respectively which would trigger the rules, but they are called anyway.

[williampma]

Have you updated to the latest version and recompile? Those rules should already be fixed. At least on my machine those rules work.

I will have to test those sentences tomorrow.

[sebastianruder]

You're right, William. It works. Didn't mean to bother you. The necessity of rebuilding after pulling the relex repo hasn't gotten stuck in my head yet. I will think of it next time. Thanks!

[williampma]

No problem. Glad to see it working for someone else beside me :)