MOSES integrated

[Nil Geisweiller]

Hi,

I've completed ComboReduct & MOSES port for opencog, there is still the warning message issue to fix though.

There is no licence at the beginning of many files but I guess that's not a problem, is it?

Nil

[Ben Goertzel]

Excellent to hear!! ;-)

A license needs to be added ... I suppose David can send you text for
the appropriate license, and then you can insert it in the files.

ben

--
Ben Goertzel, PhD
CEO, Novamente LLC and Biomind LLC
Director of Research, SIAI
b...@goertzel.org

"I don't believe in dying. It's been done. I'm working on a new exit."
-- George Burns

[Joel Pitt]

Were ComboReduct & MOSES already licensed? If so do we have the
copyright to change licenses?

If we do, then you could just pull the licence information from other
source files in OpenCog.

J

[Ben Goertzel]

They must already be licensed, as Moshe released them open-source already

David should look at the licenses involved and make sure there are no
issues. Moshe, Nil and Predrag are the authors of the code so if any
tweaks are needed they can likely be made

ben

[Nil Geisweiller]

Hi,

On Wed, Mar 11, 2009 at 8:05 AM, David Hart <dh...@novamente.net> wrote:

Hi Guys,

What's your opinion on moving opencog/moses to opencog/learning/moses? (or other similar subdirectory). Analagously, Joel located PLN at opencog/reasoning/pln.

agreed

'learning' sounds right, any other proposition before I move the code?

similarly we have comboreduct which is under opencog but I'm not sure whether it should go under learning repo I believe it shouldn't because combo (or whatever will possibly replace it) will be used by atoms too (schema node).

Nil

The reasoning behind this request is to remind developers what MOSES does at a glance, to help modularize generally, and also to avoid filling opencog/* with too many items. If opencog/moses moves for these reasons, where should comboreduct live?

-dave

[Moshe Looks]

The original combo reduct and Moses that I wrote are under Apache 2.0,
IIRC...

> _______________________________________________
> Petaverse mailing list
> Peta...@vettalabs.com
> http://vettalabs.com/mailman/listinfo/petaverse_vettalabs.com

[Cassio Pennachin]

BTW, MOSES has an official project page outside opencog.org:

http://code.google.com/p/moses/

And the licence is, indeed, Apache 2.0. Nil, I'm not sure what you
mean by completing the MOSES port to OpenCog, in this context. The
Google Code page says the last update is dated September 2008. Has a
decision to move MOSES code to OpenCog's infrastructure been made? We
definitely want to avoid having two separate MOSES code repositories...

Cassio

--
Cassio Pennachin
CEO, Vetta Labs
www.vettalabs.com -- +55(31)3421-6933

[Nil Geisweiller]

Hi,

On Wed, Mar 11, 2009 at 7:16 PM, Cassio Pennachin <cas...@vettalabs.com> wrote:

BTW, MOSES has an official project page outside opencog.org:

http://code.google.com/p/moses/

And the licence is, indeed, Apache 2.0.

if I'm correct the reason it is Apache 2.0 is because of tree.h (right Moshe?), however Moshe has developed a tree lib which is GPL and which is better than tree.h, it would be nice to be replaced at some point but we need someone for that and that's a big annoying task (although the one who would take it on would probably learn a lot about several parts of the code).
 

 Nil, I'm not sure what you mean by completing the MOSES port to OpenCog, in this context.

the version of MOSES that I've integrated in Opencog now is the one that was in the PetBrain which derived from the version at google code.

so we had 2 separate versions of MOSES for a while now, the OpenCog version relies on ComboReduct which is more generic regarding combo vocabulary and probably a few minors improvements.

Since OpenPetBrain is gonna rely on the official distro of opencog we agreed that it makes sense to integrate MOSES to opencog and also apparently the community would prefer to have MOSES internal to opencog rather than external.

Nil
 

[Moshe Looks]

Hi Nil,

Actually, the license choice had nothing to do with tree.hh, which is
in fact under GPL rather than Apache (I got special permission from
the author to use it within an Apache-licensed project). At the time
(before the choice of the GPL for OpenCog), I simply preferred the
Apache terms to the GPL terms.

As long as it is still possible to fetch and build MOSES on its own,
having MOSES internal to opencog is fine by me. If it would be huge
hassle to keep the "new MOSES" under Apache (I guess that it would be
;->) then switching to GPL is OK (in fact I think that anyone can
build on Apache code in a GPL project)...

If you can create a page with installation instructions for the MOSES
within OpenCog, we can then update the front page
http://code.google.com/p/moses/ with a link to this, and instructions
to go there for the latest code.

- Moshe

On Thu, Mar 12, 2009 at 11:51 AM, Nil Geisweiller

[Cassio Pennachin]

Hi,

>
>> Nil, I'm not sure what you mean by completing the MOSES port to
>> OpenCog,
>> in this context.
>
>
> the version of MOSES that I've integrated in Opencog now is the one
> that was
> in the PetBrain which derived from the version at google code.
>
> so we had 2 separate versions of MOSES for a while now, the OpenCog
> version
> relies on ComboReduct which is more generic regarding combo
> vocabulary and
> probably a few minors improvements.

Yes, but one of them was private. It's confusing to have two
different repositories for the same open source project.

> Since OpenPetBrain is gonna rely on the official distro of opencog
> we agreed
> that it makes sense to integrate MOSES to opencog and also
> apparently the
> community would prefer to have MOSES internal to opencog rather than
> external.

As long as Moshe is OK with that, I'm OK as well, but the MOSES
project site should be updated to reflect the new location.

Cassio

[Nil Geisweiller]

Hi,

On Thu, Mar 12, 2009 at 10:44 PM, Moshe Looks <madsc...@google.com> wrote:

Hi Nil,

Actually, the license choice had nothing to do with tree.hh, which is
in fact under GPL rather than Apache (I got special permission from
the author to use it within an Apache-licensed project). At the time
(before the choice of the GPL for OpenCog), I simply preferred the
Apache terms to the GPL terms.

As long as it is still possible to fetch and build MOSES on its own,
having MOSES internal to opencog is fine by me.

right now it is not straight forward to produce a standalone version of MOSES from the OpenCog version and I agree that it is not good (that was the main reason that had made me reluctant to put it under opencog actually).

However I'm sure that can be "scriptized", typically a bot would produce the standalone version automatically, that's what David has suggested I think.

I'm probably the right person to produce that bot, David (or anyone for that matter) do you have any suggestion aboutregarding how I could do that? (my first thought would be to just write a bash script but maybe there are other better ways).

However, maybe it can wait until OpenPetBrain port is completed, can't it?
 

If it would be huge
hassle to keep the "new MOSES" under Apache (I guess that it would be
;->) then switching to GPL is OK (in fact I think that anyone can
build on Apache code in a GPL project)...

OK
 

If you can create a page with installation instructions for the MOSES
within OpenCog, we can then update the front page
http://code.google.com/p/moses/ with a link to this, and instructions
to go there for the latest code.

OK, I'll do that as soon as I complete this bot.

Thanks
Nil

[Ben Goertzel]

> However I'm sure that can be "scriptized", typically a bot would produce the
> standalone version automatically, that's what David has suggested I think.

...

> However, maybe it can wait until OpenPetBrain port is completed, can't it?

Yes, IMO it can wait till then, but it should be done right after the
OpenPetBrain port is completed...

Until the bot is done, then we should leave the older, standalone
version of MOSES intact in its repository, of course...

ben

[Nil Geisweiller]

but there is another problem, if someone brings some modification to that extracted version of MOSES then merging his/her changes back in the opencog version is a pain.

Which means that (unless one can find a nice merging tool or technique) that extracted version would be used for users only, not developers, or destinated to be a fork opencog MOSES.

That kind of issues is exactly why I would have preferred to have an external version MOSES that OpenCog would link to...

Nil

[Ben Goertzel]

Nil,

> That kind of issues is exactly why I would have preferred to have an
> external version MOSES that OpenCog would link to...
>
> Nil

I can't remember the reasons why this was decided against (and don't
feel like searching my email archives to find out), but I do remember
it was an extensive discussion and that the decision was made with
some thought

However, it's worth noting that currently there are precisely zero
developers or users of MOSES outside of the OpenCog context. And
Moshe, who created MOSES, has moved on to Plop.

(Someone did wrap MOSES in OpenBiomind recently, but that project is
now done ... and I suspect it would be easy enough to make OpenBiomind
wrap the OpenCog-ified version of MOSES instead of the old one.)

So, I don't think we should spend too much energy fretting over the
relationship between a small developer community (OpenCog) and a
nonexistent developer community (standalone-MOSES).

I suspect that making MOSES easy to use and develop in the context of
OpenCog is going to be the best way do keep MOSES development going
forwards, because OpenCog has a developer community and
standalone-MOSES has none.

Of course, this discussion would be quite different in nature if Moshe
were still developing MOSES.

-- Ben