link-grammar conjunctions [was Re: [opencog-dev] Embodiment/RelEx2Frame issue
Linas Vepstas
On 8 July 2010 22:31, Ben Goertzel <b...@goertzel.org> wrote:
>> BTW, off-topic, but I've been working on completely re-doing how
>> link-grammar handles conjunctions (and,or,but,...) and now see
>> light at the end of the tunnel. This promises to improve performance
>> ten-fold on "real" texts, and is good for many other reasons. ... Just
>> in case you wondered what I was up to. (this is a distraction from what
>> I *really* want to do, but .. one step at a time).
>
> Awesome, Linas ;-)
>
> I'm curious to hear the details of your approach when you feel like sharing...
>
> All that business with fat links and conjunctions always seemed like
> the "dirty little secret" of link grammar --- hugely important to
> performance on real sentences, but not nearly as elegant or
> well-motivated as the main link-grammar parsing...
At some point I realized that conjunctions can be handled using
plain-old ordinary link-grammar links (although I've had to invent half
a dozen new link types to do so -- one for verbs, one for nouns, etc.)
Here's documentation for one -- the AJ link, which hooks together
adjectives.
http://www.abisource.com/projects/link-grammar/dict/section-AJ.html
(documentation is under construction)
This is the simplest of the new links; the links for nouns are harder, as they
have to enforce number agreement, and those for verbs are trickier still,
since some can take direct and indirect objects, others cannot.
I cannot discern any reason, other than some sort of historical blindness,
for why the "fat link" mechanism was created. So, for example, the rules
for verb and-links are quite complicated, and maybe back when link-grammar
was in early prototype stage, it may have seemed that and-ing together
verbs was "too complicated". In hindsight, its not "too complicated", just
slightly more complicated than average. Funny thing is that the C code
just encodes all this complexity, and the C code is dense, and its very
hard to understand/modify, and its blunt -- it allows far more possibilities
than there really are (ergo the combinatorial explosion)
Also, the new mechanism seems to provide a natural way for supporting
if...then... constructions, which currently aren't supported at all (as well
as "not only... but also..." and so on.
You can try the new code by fetching from the SVN repository. Its
still got a number of bugs, and I've still got to write the documentation,
but all of the basic issues seem to be solved, and its now just a matter
of cleaning up, testing, etc.
--linas
Murilo Saraiva de Queiroz
--
You received this message because you are subscribed to the Google Groups "OpenCog Developers" group.
To post to this group, send email to opencog-d...@googlegroups.com.
To unsubscribe from this group, send email to opencog-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opencog-developers?hl=en.
--
Murilo Saraiva de Queiroz, MSc.
Senior Software Engineer
http://www.vettalabs.com
http://www.tecnologiainteligente.com.br
http://www.acalantoemcasa.com.br
Rich Cooper
Nicely done! Will there be a Windows DLL of the upgraded version? Will the old API still hold?
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
--
You received this message because you are subscribed to the Google Groups
"link-grammar" group.
To post to this group, send email to link-g...@googlegroups.com.
To unsubscribe from this group, send email to
link-grammar...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/link-grammar?hl=en.
Linas Vepstas
> Nicely done! Will there be a Windows DLL of the upgraded version?
Only if someone makes one ...
>Will the
> old API still hold?
Yes.
The new dictionaries will more-or-less work with the old DLL's, although
there have been various other changes that would suggest using new DLL's.
One such change is a flag to get back the old behaviour.
--linas
Linas Vepstas
> Very interesting Linas...
>
> And it immediately made me think of the SAT link parser, which I
> continue to think is the best path forward for link parsing overall
> (because it gives the option to do semantic parse selection within the
> parser, not as a post-processing phase)...
I was/still am interested in having a Viterbi decoder do the parsing,
as I think that would be "more biological", should be very fast, could
be easily steered to good parse selections, and also be unconstrained
by external end-of-sentence identification. (i.e. it could identify the
end of a sentence itself).
As I contemplated doing a Viterbi decoder, I realized that I needed
to get rid of fat links as a pre-requisite.
Is there such a thing as Viterbi SAT? Without really understanding the
current SAT algos, I think there could be ...
> As I recall, the one limitation of the SAT link parser (aside from the
> lack of semantic parsing guidance, and the failure to use the "forward
> moving" structure of most sentences to guide the SAT search) was that
> it didn't correctly handle sentences with multiple conjunctions.
> There was some plan for how to handle this, but I don't remember it.
Yes, this plan required exposing the old "fat links" via the C code;
it was just complicated enough that it didn't happen.
> But if conjunctions can be dealt with without fat links, then maybe
> the new conjunction-oriented links can just be added into the rulebase
> used by the SAT link parser without making any code change, and it
> will just work....
Yes, it should "just work"
> Or maybe it won't be quite that simple...
On the other hand, it could "just work" even better if various a-priori
knowledge was applied about the new links ....
>> Here's documentation for one -- the AJ link, which hooks together
>> adjectives.
>>
>> http://www.abisource.com/projects/link-grammar/dict/section-AJ.html
>>
>> (documentation is under construction)
A general overview, also under construction:
http://www.abisource.com/projects/link-grammar/dict/conjunctions.html
--linas
Jon D.
Sorry for the late reply -- this new method of handling conjunctions looks alot like how it is done for PersianLG and ArabicLG (since 2003). I also was dissatisfied with the previous manner of handling conjunctions for English. I'm glad to see I wasn't alone in this sentiment :-)
This manner of handling conjunctions has since become known as Prague-style conjunction (eg. Smith & Eisner, 2009).
Cheers,
-Jon
--- On Fri, 7/9/10, Linas Vepstas <linasv...@gmail.com> wrote:
> Here's documentation for one -- the AJ link, which hooks
> together
> adjectives.
>
> http://www.abisource.com/projects/link-grammar/dict/section-AJ.html
>
> (documentation is under construction)
>
Linas Vepstas
> I wonder if you've thought about rules for commas yet; as I recall
> that was an annoying case...
Well, its all annoying ...
I've gotten commas to work, for creating lists of nouns and adjectives.
Commas are annoying because they are frequently mis-used. What
I do not have yet is any good mechanism for detecting such abuse,
and guessing through it; similar remarks apply for dropped words,
using "or" instead of "nor", etc.
On the other hand, I believe that if/when I really do wire up proper
statistically-guided parse-ranking, then this could be overcome.
The core database infrastructure has long been in place; I just have
to redo the databases.
I'm also excited by the idea of automatically learning grammars, I think
I have some good ways of doing this now, and am eager to exeperiment.
--linas