Posted by: bgoertzel on: 2009-11-09
Here is an update on some recent OpenCog work that may be relevant to some of you…
(Email samir@vettalabs.com if you have detailed questions)
The main update is that the “virtual pet QA system” now answers questions regarding many more spatial relationships; for the full list see
http://www.opencog.org/wiki/EmbodimentLanguageComprehension_Questions
(The work here was in creating rules to identify when these relationships hold between objects as perceived and recorded in the LocalSpaceMap. Ideally these rules would be learned of course, but for a short-cut we’ve hand-coded them…. Making these rules is easy in itself, but required various improvements to the virtual-pet perception infrastructure, which were useful improvements anyway…)
Along the way to doing this, the SpaceServer and LocalSpaceMap inside OpenCog were extended to use 3D rather than just 2D like before. What Samir and Fabricio are working on now is:
1) Loading FrameNet into the Atomspace to enable better reference resolution (this will also be useful for PLN work). They are using an XML version of FrameNet so they don’t need to spider the website…. Note that our license for FrameNet covers only research uses; you need to pay to use it for commercial apps…
2) Building a simple OpenGL-based visualizer so as to visualize what the virtual pet is seeing at each point in time (this should be useful for debugging issues with spatial reasoning, etc.). Basically this is a visualizer for the 3D LocalSpaceMap structure inside OpenCog…
Posted by: linasv on: 2009-11-08
During some recent reading, it struck me that a useful framework for thinking about and talking about sentence generation is the MTT or “meaning-text theory” of Igor Mel’cuk, et al Here is one readable reference:
Igor A. Mel’čuk and Alain Polguère, (1987) “A Formal Lexicon in Meaning-Text Theory”, Computational Linguistics, vol. 13, pp. 261-275.
portal.acm.org/citation.cfm?id=48160.48166
www.aclweb.org/anthology/J/J87/J87-3006.pdf
Within the context of that theory, the output of the Stanford parser is strictly at the SSynR or “surface syntactic representation” level, while, as a general rule Relex attempts to generate the DSynR or “Deep syntactic representation” structure. Some of what I’ve been trying to do with opencog is towards the “SemR” structure, as described in that paper.
The more I read about MTT, the more it seems to capture some of what we are trying to do (defacto are doing) with NLP within opencog. In particular, the MTT concept of a “lexical function” (which is not really described in that paper??) could be a particularly strong way of guaranteeing correct syntactic output for segsim, nlgen or NLGen2
– Linas Vepstas
Posted by: ferrouswheel on: 2009-11-03
Time that we post a status update!
OpenCog has been a little more quiet than usual over the last couple of months. The developers list is still sporadically active, but some of the main developers are having to spend time on other work related projects meaning less AGI-driven focus (want to change that? donate here). We’re following several options for establishing further funding for the end of 2009 and through 2010, but we’ll see how that goes.
Instead of writing a long summary post, I’ll just give some bullet points:
.
I’m sure there are other items of note, so to the other contributors reading this, please feel free to comment and I’ll update this post ;-)
Posted by: linasv on: 2009-10-05
I spent the weekend comparing the Stanford parser to RelEx, and learned a lot. RelEx really does deserve to be called a “semantic relation extractor”, and not just a “dependency relation extractor”. It provides a more abstract, more semantic output than the Stanford parser, which sticks very narrowly to the syntactic structure of a sentence.
I wrote up a few paragraphs on the most prominent differences; most of my updates were to the RelEx dependency relations page.
Here are the main bullet points:
Its also clear to me that I could split up the relex processing into two stages: one which generates stanford-style syntactic relations, and a second stage that generates the more abstract stuff. This might be a wise move … Since RelEx is already more than 3x faster than the Stanford parser, this could attract new users.
– Linas Vepstas
Posted by: linasv on: 2009-09-08
I’ve recently resumed work on the question-answering chatbot, and am trying to get it to comprehend a broader range of questions and statements. The “big idea” is to create a number of “sentence patterns” that the pattern matcher can recognize and respond to. The reason this is a “big” idea is because I am trying to avoid anything algorothmic or procedural — everything is to be done by specifying OpenCog hypergraphs, and NOT by writing C++ code, or scheme code (or python code…etc). The reason for working entirely with patterns and hypergraphs, rather than with C++ or scheme, is because this puts the “knowledge” of the system into a form that AI routines can manipulate it: learning algos can learn new hypergraphs; statistical algos can gather usage information on which hypergraphs get triggered, and so on. This is all easer said than done: although I’ve eliminated a fair amount of question-answering code previously written in C++, I’ve also had to write some new scheme code. Bummer. :-(
Patten matching is now used through-out all of the OpenCog NLP pipeline, although not in a unified manner. The Link Grammar parser uses patterns (called “disjuncts”) to determine how the words in a sentence can link to one-another, thus “parsing”, or pulling the grammatical structure out of a sentence (this paper provides an excellent overview). The RelEx dependency relation extractor applies patterns on the link-grammar output to extract syntactic relations. For example, the sentence “John threw a rock” becomes
_obj(throw, ball)
_subj(throw, John)
after RelEx gets done with it. And now, there are a dozen patterns inside of OpenCog that can pick out certain kinds of questions and statements from RelEx output, and pattern-match questions to find answers to them.
For example, the new OpenCog patterns convert “The capital of France is Paris” into
capital_of(France, Paris)
and similarly, “What is the capital of France?” into
capital_of(France,what)
Treating “what” as a variable, there is yet another pattern that matches up the form of the question to the form of the answer, thus deducing that “what” must be “Paris”.
Somewhat harder is using patterns to distinguish similar from dis-similar concepts, so that sentences like “John threw a green ball” aren’t used as answers to questions such as “Did John throw a red ball?”: the word “ball” with modifier “green” has to be detected as a different entity than the word “ball” with modifier “red”: these are two different entities (called “semes” in the code). In fact, out of laziness, I’ve punted on this one: the promotion of word-instances to “semes” is done by code, rather than by pattern matching. But soon, I hope, this will change. In the meanwhile, the README file provides a more detailed discussion.
Here are some patterns that work these days:
<me> John threw a green ball.
<me> Fred threw a red ball
<me> Mary threw a blue rock
<me> who threw a ball?
<cogita-bot> Syntax pattern match found: Fred John
<me> who threw a red ball?
<cogita-bot> Syntax pattern match found: Fred<me> Did Fred throw a ball?
<cogita-bot> Truth query determined “yes”: throw<me> Did Fred throw a red ball?
<cogita-bot> Truth query determined “yes”: throw<me> The color of the book is red.
<me> What is the color of the book?
<cogita-bot> Triples abstraction found: red<me> the cat sat on the mat
<me> what did the cat sit on?
<cogita-bot> Triples abstraction found: mat
And here are some that don’t yet work: “Did Fred throw a green ball?” — gets no reply, because the system can’t find an answer, and doesn’t make the common-sense leap of “can’t find answer-> answer must be no”. Another common-sense problem is illustrated by: “Did Fred throw a round ball?” — the system doesn’t know that balls are round, and simply assumes that a “round ball” is some special kind of “ball”. Oh well. There’s work to be done.
You can try out the chatbot yourself (when its up, and not broken!) on the IRC chat channel #opencog on the freenode.net chat servers.
– Linas Vepstas
Posted by: linasv on: 2009-07-06
The link-grammar parser uses labeled links to connect together pairs of words. In order to capture the idea of proper grammatical construction, any given word is only allowed to have very specific links to its right or left: for example, verbs have their subject on the left, and an object on the right. Link-grammar defines hundreds of different link types, and there are typically dozens or even hundreds of ways that these can attach to a word. Each allowed set of links is called a “disjunct”. So, for example:
MVp- Js+
is a disjunct that says “there must be an MVp link from this word, going to the left, and an Js link, going to the right”. This disjunct commonly connects prepositions to a verb on their left (the MV- link) and the object of the preposition on the right (the J+ link).
A good way to think about disjuncts is to imagine them as very fine-grained part-of-speech tags. Thus, when one sees “MVp- Js+” associated to a word, one knows not only that the word is a preposition, but even a bit more: its a preposition that took a singular object. Disjuncts classify words not just into crude part-of-speech categories, but much finer categories: thus verbs are not just as transtivie or intransitive verbs, but mgiht be transitive verbs that take both direct and indirect objects, or participles, etc.
Siva Reddy, a GSOC 2009 summer student, prepared a table of the frequency of occurrence of different disjuncts in a large collection of text. The top six entries are
Ds+ 950275.635843
Xp- 838569.90527
A+ 616522.664867
AN+ 566658.997313
MVp- Js+ 563082.649325
MVp- Jp+ 446487.310222
and these are exactly what one might expect:
A graph of rank vs. frequency is shown below:

Disjunct rank vs. frequency of occurance
As can be seen, the distribution is more or less Zipfian, with a power-law exponent of 1.5. The fact that the long tail appears to be linear indicates that grammatical construction in the English language appears to be more ore less scale-free: difficult and akward constructions are increasingly rare. The fact that the graph is not purely Zipfian, but instead has a knee for the most common grammatical connections suggests that the most common grammatical constructions are “less common than they should be”: almost as if English speakers are resisting the use of formulaic sentence constructions. So, for example, since adjectives and noun-modifiers appear near the top of the rank, this suggests that English speakers “could have” used more adjectives and noun-modifiers, but didn’t. Quite why this is so is not clear. Perhaps the use of anaphora and references in general helps decrease the need for lots of modifiers.
The open questions are then:
The corpus used here consists of approximately 1 million sentences, obtained by parsing entire Wikipedia articles, Voice of America news stories, and 10 books from Project Gutenberg, including War and Peace, Jane Austen, and some scientific or medical texts.
– Linas Vepstas
Posted by: ferrouswheel on: 2009-06-02
Recently Jared Wigmore, a student of Waikato University, New Zealand, created a tool for visualizing PLN as part of a visualisation project.
In my opinion, the BIT visualiser shows great promise as a tool for understanding the complexities of BIT expansion. In particular, the cross joins between sub-trees make it much clearer how sharing of sub-trees is occurring. The size of the BITNodes reflect their fitness evaluation in determining which node of the inference tree will be expand next and will inevitably be useful when we get to the stage of tuning the the fitness heuristic.
Being a prototype, there is plenty of scope for continued development, a couple of the many ideas that immediately come to mind are:
This is part of the bigger challenge of general AtomSpace visualisation. How do we convey knowledge about the processes that are going on in a digital mind to humans in a meaningful way?
Posted by: ferrouswheel on: 2009-04-20
The decision process for the 2009 GSoC projects has been completed. You can read Ben’s announcement on the opencog-soc Google group.
The accepted projects are:
More detail is available for each on the GSoC OpenCog home page.
Posted by: dhart on: 2009-03-25
We are happy to announce that the SIAI has been selected again this year to participate in the Google Summer of Code program as a mentoring organization. GSoC is an annual program that awards successful student contributors a 4500 USD summer stipend to work on open source and free software projects for three months. Around one thousand students worldwide participated in GSoC 2008, with eleven students working on OpenCog related projects. Students may apply for GSoC 2009, beginning at the SIAI organization page. The student application period closes on April 3, 2009 at 19:00 UTC.