Re: OpenCog.org website

[Linas Vepstas]

Naming and branding:

So here's a proposal. Four things. Four names. Four brands:

* OpenCog Classic

* OpenCog AtomSpace

* OpenCog Hyperon

* OpenCog Incubator

"OpenCog Classic" consists of everything abandoned and obsolete; This includes PLN, URE, Attention, SpaceTime, Ghost, Relex, R2L, ROS, Eva/Sophia, MOSES (but not as-moses, see below).

"OpenCog AtomSpace" includes:

-- base AtomSpace

-- CogServer and atomspace-cog (for networking, json, websockets)

-- atomspace-rocks (disk I/O subsystem)

-- Proxy Nodes (for data routing, replaces attention bank)

-- Link Grammar

OpenCog Hyperon

-- the stuff you're working on

OpenCog Incubator

-- atomspace-prolog proof-of-concept

-- chemistry proof-of-concept

-- agi-bio

-- visualization

-- as-moses

-- vision proof-of-concept

-- hyperon-on-top-of-atomspace proof of concept.

-- etc.

The above is the branding and website design that I would like to see. It makes it clear what's what, what goes where, what's alive, what's dead. what's stable, what's new.  what's broken, what's experimental. Does this work for you?

Two extra remarks:

The hyperon-on-top-of-atomspace proof of concept. Not sure if you didn't see the announcement, or you saw it and just hated it. I think putting Hyperon on top of the AtomSpace is not too hard, and I think it might work quite well, given that the code base is debugged and performance tuned. I understand that the current devel crew does not care for such a thing. But it is a viable path, and a kind of insurance policy.

Link Grammar.  I've been working to integrate Link Grammar more closely with the base AtomSpace. It turns out that Link Grammar is a generic structure parser. Or rather, is close to one, although some fair amount of bending, welding and hammering is still required. I think it can be used to process visual/video data, audio data, sensory data in general. Part of the big deal is that link-grammar is now really really fast: Amir Plivatsy has performance-tuned the heck out of it, it runs about 100x faster than it did a decade ago. And since CPU's have also gotten faster, ... wow. So that is the dataflow, or structure-flow idea. Converting any kind of streaming data into a "streaming semantic graph" in real time.

AS-MOSES: As a whole, it is problematic. There are a few pieces/parts I'd like to rip out and breathe new life into. In particular, generic "knob-turning" and deme management would be excellent stand-alone plugins for the AtomSpace. I need knob-turning in order to train on video and audio feeds.

-- Linas

On Thu, May 18, 2023 at 6:18 PM Ben Goertzel <bengo...@gmail.com> wrote:

I think Linas may not care for the appellation "Classic" for the
version of OpenCog he's currently developing and. using .. I don't
really love it either but I just came up with it casually and have
kept using it.. it was kind of a bad joke on "coca Cola Classic"
really...

Linas, how would you suggest we refer to the original, non-Hyperon
version of OpenCog on the opencog.org site... given that we want to
clearly point folks who come to the site both to a page giving
resources on Hyperon, and to resources on the other original/classic
OC version (e.g. the OC wiki, the Github repo, etc.) ...

thanks
ben

On Thu, May 18, 2023 at 12:46 PM Haley Lowy
<haley...@singularitynet.io> wrote:
>
> Hello Linas!
>
> We are planning to have our web person start with a refresh of the look and feel of the OpenCog front page - drawing largely from the content that is on the foundation site currently about the theoretical underpinnings of OpenCog and its vision and goals. We’ll then have a section that features the two versions - “Classic” (which is how we’ve been referring to the original), and “Hyperon”. We will link out to the wiki, the discord, and the google group for those who want to get involved.
>
> We will then, as Ben says, add a subdomain for Hyperon - we currently don’t have a good place to collect and highlight the features and progress of this project, so this page will allow us to do that.
>
> Mario Guzman will be doing the website design and development, and we are currently building wireframes for it, which we should be able to share early next week. We are hoping to have at least a fresh landing page and some initial resources up before AGI-23.
>
> What do you have in mind, and what are your goals for a new site?
>
> I look forward to getting to coordinate with you on this, as your passion and enthusiasm for OpenCog has been so helpful to devs and researchers who want to get involved in using this system. Thank you,
>
> Haley
>
>
> > On May 16, 2023, at 5:40 AM, Ben Goertzel <bengo...@gmail.com> wrote:
> >
> > Hey!
> >
> > It seems that two parties (Haley / SNet team) and Linas are
> > concurrently thinking about updating the OpenCog.org site in the near
> > term...
> >
> > Def. this update makes sense, the site is more than a bit stale... but
> > let's make sure we're coordinated here...
> >
> > Linas: Our plan has been to make a subdomain hyperon.opencog.org and
> > use it as a main info page on Hyperon, and then insert a link on this
> > on the (revised) front page.  I suppose this would be compatible w/
> > whatever changes you're thinking of making?
> >
> > Anyway I don't want to be in the middle here communication-wise so w/
> > this email I am aiming to put Haley and Linas in direct communication
> > on this!
> >
> > thx
> > ben
> >
> >
> > --
> > Ben Goertzel, PhD
> > b...@goertzel.org
> >
> > "My humanity is a constant self-overcoming" -- Friedrich Nietzsche
>


--
Ben Goertzel, PhD
b...@goertzel.org

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

--

Patrick: Are they laughing at us?

Sponge Bob: No, Patrick, they are laughing next to us.

 

[Ivan V.]

Hello dear OC community,

May I drop just an observation as an independent eye? How about something constructive like (based on Linas' suggestions):

1. OpenCog Genesis
2. OpenCog Hyperon
   

and additionally:

• OpenCog Fossils
• OpenCog Incubator

---

Use for Fossils is obvious, and relates to Linas' excellent idea. A lot of people tied up a valuable time in it, and holding that work in an archive like this would be a great. Who knows, maybe someone has a clue how to revive portions of those extensions.

Genesis and Hyperon would be the first two incompatible versions in a row:

• Genesis would be the current version (filtered at someone's wake eye); it already works, it already has a user base, and it is given enough attention not to just let it go like that; just package it right, and I'm sure it will have enough users. Something should be made out of it, and I like Linas' propositions.
• Hyperon would be (as a product of a lot of experimentation - not to be disregarded) an evolutionary step from Genesis; obviously, a considerable amount of effort is invested in it; it is the second, but surely not the last step in this mainstream timeline.
• And the following versions... boy, I can't wait to see what the future brings... the future is always surprisingly ingenious...
  

As a potential independent contributor, I'm particularly interested in Incubator as a place from which all the mainstream versions would be updated and refreshed by extensions worth of consideration. I like the OC openness, but I find the current strategy too chaotic to hold everything together in a right place. Incubator could solve that problem in my humble opinion. I wish there could be a clearer connection from Incubator to Genesis and Hyperon in terms of GitHub, but what we have, we have, and I'm grateful for it.

@Linas, do you have any thoughts on these suggestions or am I being too insolent?

love,

Ivan

[Linas Vepstas]

Hi Ivan,

I liked the name "Fossils" so I went ahead with that. There are now two brand-new wiki pages:

* https://wiki.opencog.org/w/OpenCog_Fossils

* https://wiki.opencog.org/w/OpenCog_Incubator

For each of the fossils, I attempted to write a post-mortem: what the idea was, what went wrong, why it didn't quite work out as hoped. I think post mortems are good: they give you time to think over what happened, to draw some lessons. A time to ponder how things could be done differently.

These are wiki pages! Those who don't agree, or have something to add, or can deduce a different set of lessons -- well, this is the time and the place for that.

There's one political statement in the middle of this: a proposal to layer MeTTa on top of the AtomSpace. From what I can tell, this would be easy to do, and, from what I've seen, you'd get a huge performance boost and instant scalability, since the AtomSpace can deal with far larger datasets than what Hyperon can currently handle. I know that this is an unpalatable pill, and will be rejected out of hand, ... but perhaps it's time to think a little more seriously about things. FWIW, the proof-of-concept is at https://github.com/opencog/atomspace-metta

-- Linas

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/opencog/f4592451-f1ff-4e73-b608-7db356e83f4dn%40googlegroups.com.

[Linas Vepstas]

Resending, because I'm not sure that everyone on the original mailing is subscribed to the mailing list.  -- Linas

[Ben Goertzel]

LInas, quick question, do you prefer the nomenclature "OpenCog
Classic" or "OpenCog Genesis" for the version of OC you're currently
maintaining / lead-developing?

As a side comment, I am thinking mid-fall Hyperon will be at a stage
where it makes sense to aggressively try to grow the Hyperon OSS
development community ... More on this later!

ben

> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/opencog/f4592451-f1ff-4e73-b608-7db356e83f4dn%40googlegroups.com.

[Linas Vepstas]

Hi Ben,

The current wiki is organized as follows:

Naming and branding: Four things. Four names. Four brands:

* OpenCog Fossils

* OpenCog AtomSpace

* OpenCog Hyperon

* OpenCog Incubator

"OpenCog Fossils" consists of everything abandoned and obsolete; This includes PLN, URE, Attention, SpaceTime, Ghost, Relex, R2L, ROS, Eva/Sophia, MOSES (but not as-moses, see below). https://wiki.opencog.org/w/OpenCog_Fossils

"OpenCog AtomSpace" includes:

-- base AtomSpace

-- CogServer and atomspace-cog (for networking, json, websockets)

-- atomspace-rocks (disk I/O subsystem)

-- Nil's Unifier

-- Proxy Nodes (for data routing, replaces attention bank)

-- Link Grammar

OpenCog Hyperon

-- the stuff you're working on

OpenCog Incubator  https://wiki.opencog.org/w/OpenCog_Incubator

-- SQL bridge

-- chemistry proof-of-concept

-- agi-bio

-- visualization (explorer & cogprotolab)

-- as-moses

-- typescript (javascript) bindings

-- vision proof-of-concept

I am still hoping that you will look at and provide a response to the idea of the hyperon-on-top-of-atomspace prototype. I think it is the easiest way for you to get a fast & scalable Hyperon working, right now, while you wait for the more whiz-bang thing to be developed. It will at least allow for basic progress and exploration.

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBcSSmk2Of4uVuz3S-GLwN_m8d29d82OfKFJKY2pDAUd7w%40mail.gmail.com.

[Ben Goertzel]

> I am still hoping that you will look at and provide a response to the idea of the hyperon-on-top-of-atomspace prototype. I think it is the easiest way for you to get a fast & scalable Hyperon working, right now, while you wait for the more whiz-bang thing to be developed.

I can see some short-term advantages to doing it that way, however we
are currently focusing effort instead on optimizing the Rust Atomspace
that's integrated w/ the MeTTa interpreter ...

For speedup Greg Meredith and team are working on a system that maps MeTTa into
rholang and then executes MeTTa programs using the rholang
interpreter, which makes very efficient use of multithreading using
Greg's rho calculus ... it's pretty cool stuff... it is indeed quite "whiz-bang"
and not ready for prime-time yet but we are supposed to have an alpha
by end of August.... Rholang involves a quite different method of
dealing w/ concurrency than the C++ Atomspace, if you take a close
look you'll probably like
it...