Fwd: [WG] Integrating Word Grammar with Link Grammar & probabilistic logic

[Linas Vepstas]

I should be cc'ing both mailing lists; this is discussing plans for implementing the link-grammar parser within opencog, so that e.g. references across multiple sentences could be resolved, as well as the automated learning of parse rules.

-- Linas

---------- Forwarded message ----------
From: Linas Vepstas <linasv...@gmail.com>
Date: 8 April 2013 10:11
Subject: Re: [WG] Integrating Word Grammar with Link Grammar & probabilistic logic
To: Word Grammar <WORDG...@jiscmail.ac.uk>

On 8 April 2013 09:18, Ben Goertzel <b...@goertzel.org> wrote:

> FYI, after some further reflection, I realized that I really needed the
> pattern matcher, and that's only available in the atomspace.  So I'm
> planning on moving all the viterbi work over to the opencog atomspace.
> Texas two-step -- one step forward, two steps back.   Performance will be a
> huge issue.  Applying a sequence of rewrite rules to an opencog hypergraph
> is going to be orders of magnitude slower than the optimized C code that's
> in link-grammar today.   I'm agonizing over this.

I suppose you'll have to implement some "local cache" associated with the
AtomSpace, that uses direct pointers without any intervening baggage
to slow things down?

No .. the atomspace is my 'cache'.

My plan is this: 

Write all parsing rules as ImplicationLinks  (these are graphical re-write rules that say, "if graphical pattern P is seen, then create graph Q"  so for example "if next word is a noun and previous unsatisfied link is a determiner, then create a link between noun and determiner")

ImplicationLinks are evaluated by the pattern matcher.  The pattern matcher currently uses the AtomSpace API's. Its  likely that the pattern matcher could become much faster if it worked with atoms directly; however, this is not my current focus.  Hmm. I realize as I write this that one of my performance concerns is not actually valid...   still, there's just enough additional complexity that I doubt that parsing would be competitive with the current link-parser, which is very highly optimized.

(the pattern matcher should really be a part of the atom table itself, and thus could/should access atoms via raw pointers; I see no reason for leaving it 'out in the cold', esp as I expect it to be central to allowing and maintaining 'user-defined indexes', which are stored in the atom table).

The point of using a sequence of ImplicationLinks is that, in principle, I might be able to use machine learning to have the system automatically learn new parse rules and/ore modify the sequence of rules that get applied. But this is a very fuzzy idea right now.  Some 'deep learning-ish' ideas...

The point of doing this in the atomspace is that, by having the room for multiple sentences, there could be ImplicationLinks for resolving references (e.g. determiners anaphora,etc) between sentences.   Of course, for embodiment, creating links between determiners "this" and objects in the visual field; and the exciting notion that this might resolve parse ambiguities.   That, and the ability to assign probabilities and collect statistics about probabilities. 

-- Linas

[Ben Goertzel]

> (the pattern matcher should really be a part of the atom table itself, and
> thus could/should access atoms via raw pointers; I see no reason for leaving
> it 'out in the cold', esp as I expect it to be central to allowing and
> maintaining 'user-defined indexes', which are stored in the atom table).

That seems a valid design strategy..

However, I wonder what happens to the "multithreaded Atomspace" issue
in this case?

-- Ben

[Duane Searsmith]

FWIW, I've been working on implementing the current atom space implementation in go.  I'm hoping to make it a simpler code base and to leverage go's concurrency and scalability.  Right now I have most of the indices implemented and I am working on filling out the atomtable.

I don't know if this will be of interest to the opencog community or not -- if so, I'm happy to share.  I'm doing it primarily for myself to learn about both opencog and go.

Best,

Duane

--
You received this message because you are subscribed to the Google Groups "link-grammar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to link-grammar...@googlegroups.com.
To post to this group, send email to link-g...@googlegroups.com.
Visit this group at http://groups.google.com/group/link-grammar?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Goertzel]

That seems interesting... if it performs really well it will be of
interest to the OpenCog community ;)

ben g

--
Ben Goertzel, PhD
http://goertzel.org

"My humanity is a constant self-overcoming" -- Friedrich Nietzsche

[Duane Searsmith]

Hi Ben,

It is a small work in progress.  I would be very happy if it could be of service.

I am pouring over the atomspace code in this process as you might imagine.  I hope that my observations can be useful to the project.

I am a big fan of this line of research (AGI etc...)!

Thanks,

Duane

[Linas Vepstas]

On 8 April 2013 11:22, Ben Goertzel <b...@goertzel.org> wrote:

However, I wonder what happens to the "multithreaded Atomspace" issue
in this case?

I think I know how to make this work.  Anyway, its not multi-threaded now; the current atomspace  design makes it look as if it was, by funneling everything down to one thread.  (thus, atomspace users can be multi-threaded, the atomspace itself is not). 

The penalty is a 10x-100x performance  slowdown; I measured recently, placed results in opencog/benchmark/diary.txt

one week ago, the performance was this:

   test            AtomTable    AtomSpaceImpl    AtomSpace

   name            K-ops/sec      K-ops/sec      K-ops/sec

   ----            ---------    -------------    ---------

  addNode            256.4         31.7            30.0

  addLink (***)      172.4         25.06           24.3

  getType           2500          833              26.1

  getTV             2000          625              44.2

  setTV             1666          625              63.7

  getHandleSet         2.16         1.50            1.28

  getNodeHandles      29.3         26.1            13.76

I overhauled the atomspace and discarded HandleLists, converted incoming links to an index, got rid of HandleEntry entirely and killed some other things as well.   Performance almost doubled, and I can now get almost the same performance with an atomspace that is 4 times larger.

Anyway: you can see the vast performance difference between the atom table and the atom space for just about every op.

The pattern matcher does almost nothing except getOutgoingSet and getIncomingSet and then calls getTV and getType on these. As you can see, there is a 20x or 30x perf difference here.

btw getting rid of HandleEntry was critical for making the atomtable multi-threaded;  it was an arcane mass of code that was nearly impossible to lock properly; it was one of the primary stumbling blocks.

I did all this in a coding frenzy; i've had quite enough for now.

-- Linas

[Linas Vepstas]

Hi Duane,

On 8 April 2013 12:31, Duane Searsmith <dsear...@gmail.com> wrote:

FWIW, I've been working on implementing the current atom space implementation in go.  I'm hoping to make it a simpler code base and to leverage go's concurrency and scalability. 

I was blown away to read this.  Sorry for the delayed response; I am very very excited by this news.

 

Right now I have most of the indices implemented and I am working on filling out the atomtable.

OK, well, before you get too far, we should talk in depth.  There is a lot of cruft in the API, stuff that is there for historic reasons, backwards compatibility, etc. that a new implementation does not need, and should not support.

Perhaps the biggest question is whether any effort should be made to be compatible with the existing C++ api.  I want to strongly argue that the answer is no.   I claim that, for future development, the only thing that a "real" atomspace needs to support is the ability to receive expressions such as this, coming over the wire:

 (SimilarityLink (stv 1.0 1.0)

        (NumberNode "0.24")

       (AtTimeLink (stv 1.0 1.0)

                (GroundedSchemaNode "ActivationModulatorUpdater")

                (ListLink (LemmaNode "thing1"))

        ))

i.e. take the above, and save it.  To regurgitate what it knows,  it needs to have a built-in pattern matcher, so that users can ask for all atoms of some given type and connections and etc.  So, for example, it would be like an SQL query, but for graphs:

get all graphs that match 

  (SimilarityLink 

        (VariableNode "var A")

       (AtTimeLink (stv 1.0 1.0)

                (VariableNode "var B")

                (ListLink (LemmaNode "thing1"))

        ))

which would then find the first example graph, and return that.  There's a wiki page on how this works.  I think these are the only two functions that an atomspace needs, the rest is all cruft.

Most existing code could not use such an API, and could not be easily ported to it.  However, I'm not sure how much of the existing code is interesting in the long term.   I suspect that Ben will remind me that we're pretty married to the C++ API, warts and all.   But the above API, if it was fast, distributed, scalable, cloud-able, etc. .. that would open a lot of very interesting possibilities, to me.

-- Linas

p.s. cc'ing Boris as this pertains to another conversation: if the hypergraphDB supported just the above, that would be very cool.

[Joel Pitt]

I've been mulling over this in the background.

I'm pretty much all onboard with what Linas is suggesting, I'm just not so sure about trying to maintain the lisp syntax.

I've been thinking it'd be nicer to have a whitespace sensitive (like python) DSL, something like:

rule

     inference_link A

          node X

          node Z

     inference_link B

          node Z

          node Y

where

     B.weight > 0.5

     A.name == "bob"

prefer

     inference_link.weight    # prefer links with more weighting

     inference_link.sti          # prefer links that have more STI (short term importance)

do

     create

          link type:A.type C # or just "inference_link" NEW

              node X

              node Y

     with

          C.weight = A.weight * B.weight

The above would be for a production rule, stored within the AtomSpace. Tokens starting with capital letters are variables (which saves typing "VariableNode" everywhere). Where and prefer are optional for guiding matches. The dot prefix allows access to any atom property, and it'd be nice to allow these to be arbitrary.

To just create new structures/atoms, you'd take the inside of the "do" block and remove variables.

I'd imagine they'd also be a "match" block that could substitute for "rule", the difference being that a match block does not expect an action (the "do" block).

This is quite different from the existing format, and am not suggesting it should necessarily be used, but after Linas's blog post I've been thinking about implementing something like this regardless... so thought I'd mention it.

I've been reading about a few query languages for graphical data, such as Cypher (in Neo4J), Gremlin (from TinkerPop), and SPARQL (for RDF stores). But none of them really satisfy what I'm looking for and are slightly obtuse and hard to understand. I think enforcing white space formatting adds clarity in the same way as it does in Python and Haskell.

--

[Joel Pitt]

Definitely no reason not to use protocol buffers on the wire. This would purely for human-interaction/representation.

On 9 April 2013 16:31, Mark Friedenbach <ma...@friedenbach.org> wrote:

if we're talking about a wire-serialization format, is there really a need for yet another custom human-readable syntax? How about a protocol-buffers binary serialization? It's be future-proof, compact, and with many tools to work with. It'd also have the distinct advantage of making it easy to generate API's in multiple languages.

Mark

--
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 opencog+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/opencog?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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 opencog+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/opencog?hl=en.

[Linas Vepstas]

On 8 April 2013 23:26, Joel Pitt <joel...@gmail.com> wrote:

I'm pretty much all onboard with what Linas is suggesting, I'm just not so sure about trying to maintain the lisp syntax.

 

Yeah, that's fine,  tab indents are fine; whatever, it doesn't matter.

I've been thinking it'd be nicer to have a whitespace sensitive (like python)

Sure. I look at your proposal and I see "syntactic sugar". There are tools, such as macro engines, which are designed to switch from one syntax to another; e.g. convert parens to tabs, and back again. I don't really care.  Let different users invent their own syntax.    For example, the current relex has its rules in an extremely tiny, terse format: your example would be maybe 2-3 lines in relex.  Aside from the fact that the relex format is completely ugly, its "just fine" and quite usable.  I'd be happier if it looked more like caml.  Whatever.  Pre-processors can convert formats.

What I *do* care about is actually having one system that provides the (appropriate) super-set of all these features and functions.  And the interpreter that implements all of them. That's the hard part.

 BTW, the only other thing I care about is this: every rule itself *must* be representable as a hypegraph.   Thus, It must be possible to take the example you gave, and store it in the atomspace itself.

The reason that this is important to me is because I plan to have a machine learning system automatically deduce the rules, on its own.  This is also a reason I'm not too picky  about the syntax -- I am not planning on reading or writing all that many -- only enough to understand the general problem, and then bootstrap things.  The simpler the syntax, even if its verbose, that's fine -- machine learning will work more easily with small, simple rules and a small simple syntax (think 'deep learning')  

The only other thing I'd be picky about is to make sure that the syntax doesn't accidentally hide a 'feature' that is CPU-intensive, or is incredibly hard to implement, or causes some kind of bloat.

-- Linas

[Ben Goertzel]

Linas,


Your new, simple API suggestion is certainly interesting... I find
this direction exciting, inspiring and promising...

Also, it ties in with stuff Shujing and I have been discussing
regarding algorithms for hypergraph mining.... Her pattern miner
would fit in very naturally with this API

> Most existing code could not use such an API, and could not be easily ported
> to it. However, I'm not sure how much of the existing code is interesting
> in the long term. I suspect that Ben will remind me that we're pretty
> married to the C++ API, warts and all. But the above API, if it was fast,
> distributed, scalable, cloud-able, etc. .. that would open a lot of very
> interesting possibilities, to me.

Which code is interesting in the long term, is not always easy to
say.... Much of the code one thinks will last, ends up getting
replaced with better things rapidly; and sometimes code that one
thinks will be obsoleted quickly, winds up lasting forever (for either
good or bad reasons).... I guess you know this better than I do...

However, there is certainly current code using the Atomspace which is
valuable in the medium term.... I'm thinking especially of
Embodiment code, which creates Atoms representing stuff perceived in a
virtual world, and sends action signals based on Atoms representing
actions...

There is also PLN and ECAN code which is of value...

Ruiting's in-progress NLP code just creates Atoms using the Scheme
shell, and should be compatible with your new suggestion...

So my own current, tentative feeling is

-- it could well be sensible to replace the Atomspace API with
something based on your new thinking

-- it should be feasible to port the existing useful code over to a
new API ... but it might be a lot of tedious work in some cases...

Anyway I don't think your suggestion is infeasible, it's certainly
worth considering.... We shouldn't consider ourselves "married" to
the current AtomSpace API at this point...

OTOH, the possibility of making the current AtomSpace API a wrapper
for your suggested API, also seems worth considering, at this point..

> I think these are the only two functions that an atomspace needs, the rest is all cruft.

I'm wondering about the indices...

Let's suppose we want to apply some process to only those Atoms with
ShortTermImportance greater than some threshold.... ECAN does this,
for example....

Currently this is achieved via an index of Atoms by STI. How would
this be done in your proposal?

Or, suppose you want to remove from RAM the Atoms with lowest
LongTermImportance...

Again, this is currently achieved via an index of Atoms by LTI....
How would this be done in your proposal?

thx
Ben

[Matthew Kaufman]

Hey guys; interesting discussions here....

[Duane Searsmith]

Hi Linas,

In reading through the current source I saw all of the changes you had made and I had read through your diary file with the different benchmarks. The code base looks like a code base you would find in a research project that has weathered many years -- basically efficient but with legacy retrofits and bits of cruft strewn about. Some things I haven't implemented because I could not find that they ever got used through any API. Other things did not make sense to me. I would greatly appreciate any guidance as to what classes/structures/features are no longer relevant etc...

Regarding the API, I think the simpler the better. You are much more familiar with the use cases (and given the input from others on this thread) so I am happy to go the route you suggest. I'm just trying, at the moment, to get to the point of being able to recreate the benchmarks you did to get a rough idea of what performance is like at a very low level.

I'll have more to report soon ...

Best,

Duane

--

[Linas Vepstas]

On 8 April 2013 23:26, Joel Pitt <joel...@gmail.com> wrote:

I've been thinking it'd be nicer to have a whitespace sensitive (like python) DSL, something like:

Joel, a quick apology. I suspect my response was perhaps a bit insulting, and that this dampened your spirit. (I know I get insulted when I get emails like what I wrote).  Sorry; your idea is still a good idea, and having a good, easy-to-read, easy-to-author infrastructure is important.

--linas

[Linas Vepstas]

On 9 April 2013 07:20, Duane Searsmith <dsear...@gmail.com> wrote:

Hi Linas,

Some things I haven't implemented because I could not find that they ever got used through any API. Other things did not make sense to me. I would greatly appreciate any guidance as to what classes/structures/features are no longer relevant etc... 

At this time, the class AtomSpace represents the officially supported API.  I'm looking at it now ... 

addPrefixedNode is sugar-coating, non-essential.  The half-dozen addLinks are also clearly sugar-coating.

The getHandle(type, string) and getHandle(type, outgoing_set) are interesting.  Both of these resolve into index lookups in the atom table, and thus respond "quickly", i.e. avoid a massive search of the atomspace.

I don't know what code uses these, if any. If there is code that uses these, I suspect that this code is actually implementing some sort of ad-hoc search for some particular kind of graph.  In that case, replacing it with an invocation of the pattern matcher will almost surely result in smaller, cleaner, simpler code.   

Thus, my knee-jerk reaction is that these should be removed from the API.  Perhaps   there's some other good argument to keep them. 

The entire zoo of getHandleSet() methods are covered by the above argument.  The filter() methods likewise.   Except that the argument to abolish is even stronger, in this case.

getMean, setMean are more sugar.  

cloneAtom is an affront to humanity and should be exterminated with prejudice.  Err ... well .. its there as a kludge, a recognition that accessing an atom directly, to obtain    and set truth values and attention values is actually 20x or 30x faster than calling atomspace.getTV(Handle) which requires a round-trip, a handle-to-atom-pointer lookup, etc.   Thus, cloneAtom is an attempt to give users direct, high-speed access to individual atoms, yet doing it safely, so that there are no race conditions, thread-safety issues, dangling pointers.  I'm interested in other ways of solving these issues, but I suppose that perhaps cloneAtom() is a reasonable stop-gap for now.

The 'signal' API should be cleaned up.  There are valid reasons to get notified when an atom is changed.

The 'fetchAtom' and 'storeAtom' methods are a work-in-progress.  In some ideal world, all atoms are visible to everyone, all the time, and have no cost associated with accessing them.   In real life, RAM is not big enough to contain all atoms, so some must reside on disk (or perhaps can be fetched from other, remote atomspaces).  There are *huge* performance advantages to allowing algorithms that are aware of this distributed nature, and to managing the fetch and store (instead of forcing the atomspace to second-guess).

If and when we gain more experience with distributed algorithms on the atomspace, then perhaps one day, those algos could layer on top of and thus, hide the fetch and store  methods.   Until such a day .. there they are.

--linas

 

[Borislav Iordanov]

Hi,

It has the saving part, but not the pattern matching. I'd need to port
your pattern matcher. I don't suspect this to be very hard as there
are many things in place to help build such a thing, and I've also
spend some time thinking about it so I believe I know what I'd be
getting into. I'd be happy to see HyperGraphDB be of use to OpenCog
or your new parser so I'd gladly make an effort in that direction. I
didn't end up porting it in C++ in part because that would have meant
rewriting the atomspace and I don't think anybody was ready for that a
few years ago, and we had technical disagreements about how to do it
etc.

Having it distributed would require some trade-offs to be made. To
make the long story short, it would be probably best not to use
BerkeleyDB and forget about ACID transactions. Also, distribution can
be done either at the level of the underlying key-value store or at
the level of atoms, each choice with different consequences. There is
a student that's been trying to replace BDB with Hazelcast and
hopefully soon we can run some experiments. At the atom level, there
is a framework to do P2P distribution (using XMPP) and that has been
successfully using a few applications - most recently to build a DVCS
for OWL, and it's relatively solid.

In any case, I enthusiastically applaud your recent efforts with the
parser and the atomspace cleanup/redesign!

Best,
Boris

--
https://plus.google.com/u/0/106165351435577158822/posts

"Damn! The world is big!"

-- Heleni Daly

[Joel Pitt]

While I remember... Facebook recently released a graph db benchmark tool:

http://gigaom.com/2013/04/01/facebook-builds-a-database-benchmark-for-a-graph-powered-world/

[Linas Vepstas]

On 9 April 2013 19:18, Borislav Iordanov <borislav...@gmail.com> wrote:

Hi,

>  I claim that, for future development, the only thing that a
> "real" atomspace needs to support is the ability to receive expressions such
> as this, coming over the wire:
>
>  (SimilarityLink (stv 1.0 1.0)
>         (NumberNode "0.24")
>        (AtTimeLink (stv 1.0 1.0)
>                 (GroundedSchemaNode "ActivationModulatorUpdater")
>                 (ListLink (LemmaNode "thing1"))
>         ))

> p.s. cc'ing Boris as this pertains to another conversation: if the
> hypergraphDB supported just the above, that would be very cool.

It has the saving part, but not the pattern matching. I'd need to port
your pattern matcher. I don't suspect this to be very hard as there
are many things in place to help build such a thing, and I've also
spend some time thinking about it so I believe I know what I'd be
getting into.

There are definitely some ugly parts to it, and the upper layers could use some redesign. The lower layers, which do the 'heavy lifting' of graph traversal, work great.   The upper layers were meant to make it easy to adapt to different users & uses .. this was not so successful.

 

 I'd be happy to see HyperGraphDB be of use to OpenCog
or your new parser

I've barely started, but the core idea is that parsing is done by applying a sequence of ImplicationLinks as each new word comes in.  Because each ImplicationLink is a hypergraph itself, and their application happens in the guts of the atomspace itself, there is really not much code that is outside of the atomspace.  Thus it would be 'easily' portable.

Viz, the only things that happen outside of the atomspace is, on startup, to load the sequence ImplicationLinks. Then as each word comes in, push that to the atomspace (where the implications do their work).   To get output, there would be a periodic poll: "do you have a complete sentence yet, or at least a nice meaningful fragment?"  

So that's really very little code; its essentially scaffolding, to initialize on start, and feed words in from some source of sentences -- that's all.  That's when it occurred to me that it could run on any suitable atomspace: as long is it can be fed structures (with or without parens or tabs for indentation .. anything resembling the above) then it should work.

There will be, no doubt, some hard parts.  My goal is to not break the paradigm I've just outlined; I'm quite certain it can be done; the question is how much struggle will be required.

I see no particular reason for it to be distributed at this time.

I have *not* yet thought about the database aspects of all of this. At some future date, I want  to keep parse statistics;  there are 80K-120K words in English; these can fit in RAM.   But there are millions of basic concepts (e.g. 'bicycle seat') synonyms ('next to' means 'neighboring') or facts ('Berlin is the capital of Germany') These won't fit in RAM, and besides, these need to be backed up and saved for 'next time'.  How this would work, I don't yet know.

Anyway, it seems reasonable to think that there could be other uses that would resemble the above: so as long as the atomspace/hypergraphDB supports such core functions, it shouldn't matter what's underneath. 

-- Linas

[Linas Vepstas]

On 9 April 2013 19:18, Borislav Iordanov <borislav...@gmail.com> wrote:

 forget about ACID transactions. 

I believe I don't care about that.  However, I am concerned about corruption: if I have a 100MB file of data that took years to accumulate, and a cosmic ray flips a few bits on the disk, I don't want to loose the entire dataset.  So this kind of 'fault tolerance of memory' seems to be important.

--linas

[Joel Pitt]

I think cosmic rays are a case for backups and a hardware concern (RAID or ECC memory).

The durability part of ACID is about gracefully restoring after lost power or db crash.

Of course, you *could* checksum stuff in software, but that would greatly reduce performance!

--

[Linas Vepstas]

On 9 April 2013 20:19, Joel Pitt <joel...@gmail.com> wrote:

I think cosmic rays are a case for backups and a hardware concern (RAID or ECC memory).

Bad example then. Suppose the data corruption was to to software error, but was not discovered for years, when something else bad happened.   You might have backups, but they may not help -- they may also be corrupted.

I've seen this happen on modern times, when RAID disk  arrays sometimes become unrecoverable (e.g. during recovery after one failure, the stress on the other disks is so high that another one fails. Yoww ...)

I'm also old enough to have used dBase, foxBase and etc and am quite aware of how easily/frequently those got corrupted in a fatal, unrecoverable manner.  I don't want repeats of that... 

--linas

[Borislav Iordanov]

Thanks Joel, that looks useful!

[Borislav Iordanov]

>> It has the saving part, but not the pattern matching. I'd need to port
>> your pattern matcher. I don't suspect this to be very hard as there
>> are many things in place to help build such a thing, and I've also
>> spend some time thinking about it so I believe I know what I'd be
>> getting into.
>
>
> There are definitely some ugly parts to it, and the upper layers could use
> some redesign. The lower layers, which do the 'heavy lifting' of graph
> traversal, work great. The upper layers were meant to make it easy to
> adapt to different users & uses .. this was not so successful.

Ah, well, HyperGraphDB mostly has well working lower layers as well :)
But I'm sure I could use something from the upper layers.

>>
>> I'd be happy to see HyperGraphDB be of use to OpenCog
>> or your new parser
>
>
> I've barely started, but the core idea is that parsing is done by applying a
> sequence of ImplicationLinks as each new word comes in. Because each
> ImplicationLink is a hypergraph itself, and their application happens in the
> guts of the atomspace itself, there is really not much code that is outside
> of the atomspace. Thus it would be 'easily' portable.
>
> Viz, the only things that happen outside of the atomspace is, on startup, to
> load the sequence ImplicationLinks. Then as each word comes in, push that to
> the atomspace (where the implications do their work). To get output, there
> would be a periodic poll: "do you have a complete sentence yet, or at least
> a nice meaningful fragment?"
>
> So that's really very little code; its essentially scaffolding, to
> initialize on start, and feed words in from some source of sentences --
> that's all. That's when it occurred to me that it could run on any suitable
> atomspace: as long is it can be fed structures (with or without parens or
> tabs for indentation .. anything resembling the above) then it should work.
>
> There will be, no doubt, some hard parts. My goal is to not break the
> paradigm I've just outlined; I'm quite certain it can be done; the question
> is how much struggle will be required.
>
> I see no particular reason for it to be distributed at this time.

It sounds like you'd have a massive amounts of rules/ImplicationLinks
to apply, which would beg for distributed processing at some point.
But that's the sort of distributed processing that's specific to an
algorithm and therefore probably much easier to implement than a
generic DB distribution that has to be smart and adaptive and work
well for a wide variety of algorithms.

Boris

[Linas Vepstas]

On 9 April 2013 22:16, Borislav Iordanov <borislav...@gmail.com> wrote:

It sounds like you'd have a massive amounts of rules/ImplicationLinks
to apply, which would beg for distributed processing at some point.

For comparison, relex currently applies 159 rules for part-of-speech, gender, tense, noun-number, etc. tagging, and 186 rules for 'semantic' extraction.

Before writing the above sentence, I had it in my mind that I could parse with far fewer rules than that (i.e. that all of the complexity is in the link-grammar dictionary, not in the parser itself) but it does give one pause.

--linas

 

[Duane Searsmith]

Thanks, Linas!  This is very helpful.

Best,

Duane

--