Newbie

[buj]

Hello,

I am interested in contributing to the project, mainly the atomspace part of it. I believe I will be just fine with all the documentation and wiki. However, as I am new, it would be good if I could "check my understanding" of something before I make significant changes to documentation (changes to code are of less concern, as there are pull requests and stuff and it is well organized). Where would be the right place to ask such (possibly, but not necessarily petty) questions? There is no channel on slack dedicated to atomspace. The wiki discussion pages... are not particularly well suited for discussion.

Thanks.

[Linas Vepstas]

Hi!

On Fri, May 24, 2019 at 3:07 PM buj <bujt...@gmail.com> wrote:

Hello,

I am interested in contributing to the project, mainly the atomspace part of it. I believe I will be just fine with all the documentation and wiki. However, as I am new, it would be good if I could "check my understanding" of something before I make significant changes to documentation (changes to code are of less concern, as there are pull requests and stuff and it is well organized). Where would be the right place to ask such (possibly, but not necessarily petty) questions? There is no channel on slack dedicated to atomspace. The wiki discussion pages... are not particularly well suited for discussion.

The mailing list is fine. That is, I pay attention to it :-)

So ... here's the status, as I see it.

-- I think the documentation as-such is adequate; it explains most things.

-- BUT what is missing is a slick, impressive modern website explaining what the atomspace is, and  containing demos/how-tos that are actually useful for real-life users who wandered in randomly off the net. 

-- This lack is the #1 killer of the popularity of the atomspace: everyone seems to look at it, got WTF? and then leave... we haven't figured out how to give it a front-door that is easy to walk through, and a reception room that isn't a total chaos of obscure database and knowlege-representation theory.  The cognitive overload is too high...

Code is in a similar state.

-- It is mostly "done". There's a handful of "beginner bugs" that could be fixed, but after that, its more-or-less code-complete.

-- There are a large number (a dozen or so) big, complex, rambling ideas for deep and fundamental new features to be added. But these are really far away from "newbie"; they require difficult thinking and difficult planning, and lots of prototyping, and the expectation that the first three prototypes will be total failures. I mean, -- they are hard even if you're a long timer.

Examples

-- I think the current examples are "adequate"

-- HOWEVER ... almost none of them are relevant to any kind of joe-average database shopper. If the hypothetical joe-average has fooled with any of the dozen(s) of graph databases out there, and then they look at the atomspace, they will go WTF? and just leave. We don't have any compelling examples that show why the atomspace is better than e.g. grakn.ai or tinkerpop. (it is, we just don't have those demos)

Whatever. If you're thinking of big changes to the wiki, let me know.

-- Linas

--

cassette tapes - analog TV - film cameras - you

[buj]

Thanks for the introduction.

Speaking of people randomly wandering to opencog and going WTF... I figured my current understanding of things might reveal some, let's say, common pitfalls. Which might lead to better documentation, ... so here goes.

Today I was trying to wrap my head around what the atomspace is, what it actually does and what it does not. My current hypotheses:

• The meaning of the atoms is determined through cog-execute! and cog-evaluate! (or something else in other-language-bindings). Without them, the atoms do not carry any meaning of their own, they would merely be data structures. The result of an evaluation is a truth value that is then attached to the link being evaluated, the result of execution could theoretically be anything (based on link type) -- it simply does something with the atomspace.
• Atoms are something which "is of some interest" to the user---evaluatable atoms which return bools can be thought of as the "things which (do not) hold in this axiomatic system". But this does not hold for non-evaluatable atoms: indeed, if there is (GreaterThan (Variable "$x") (Number 42)) in the atomspace, it does not mean that all X are greater than 42. The aforementioned link could have been part of something greater, such as (Get (<aforementioned>)). So, the meaning of all atoms is determined by the user and the way he uses them...? Or is there something deeper (such as in prolog, where things which are "in the system" are considered "true")?
• Some links seem to either be missing (PartOfLink, ...) or their behaviour is not as expected (AbsentLink and PresentLink cannot be cog-evaluated, why?). Maybe something needs to be imported? If so, what? It would be nice to list it in the documentation (wiki).
• SatisfyingSetLink: wiki states that
  

   EvaluationLink
     PredicateNode "breathe"
     ListLink
       ConceptNode "animals"
       ConceptNode "air"

  is equivalent to this:
  

   MemberLink
     ListLink
       ConceptNode "animals"
       ConceptNode "air"
     SatisfyingSetLink
       PredicateNode "breathe"

  So I would assume that with either of them, the query (Get (Evaluation (Predicate "breathe") (List (Variable "$x") (Concept "air")))) would return a set containing (Concept "animals"). But in the latter case, it does not. So... the two ways of representing "animals breathe air" are equivalent, but incompatible? Is it the user's job to use one or the other, or to somehow integrate them if he wants to use them in tandem?
  

And other documentation-oriented stuff:

• Scheme interface: cog-bind, cog-satisfy, cog-satisfying-set are either not documented, or obsolete. But they are still mentioned here and there on the wiki. I suppose the up-to-date way to do these is to do (cog-execute! (Bind ...)), (cog-evaluate! (Satisfaction ...)) and (cog-execute! (Get ...)). Also, many scheme functions were recently removed (such as cog-tv->alist), but they are still in the wiki. I can try clean up what I find.

That's it for now.

[Amirouche Boubekki]

I can help regarding the website. I will follow closely the conversation.

I hope it doesn't end up like my Link Grammar website...

[Linas Vepstas]

Hi,

Good questions!

On Sat, May 25, 2019 at 6:09 PM buj <bujt...@gmail.com> wrote:

Thanks for the introduction.

Speaking of people randomly wandering to opencog and going WTF... I figured my current understanding of things might reveal some, let's say, common pitfalls. Which might lead to better documentation, ... so here goes.

Today I was trying to wrap my head around what the atomspace is, what it actually does and what it does not. My current hypotheses:

• The meaning of the atoms is determined through cog-execute! and cog-evaluate! (or something else in other-language-bindings). Without them, the atoms do not carry any meaning of their own, they would merely be data structures. The result of an evaluation is a truth value that is then attached to the link being evaluated, the result of execution could theoretically be anything (based on link type) -- it simply does something with the atomspace.

Yes. There is a vague plan to merge  cog-execute! and cog-evaluate! into one. Assorted subtleties and lack of urgency are currently blocking this.

More generally, "meaning" is carried by networks, not atoms. So, for example, many ontologies have only one relation -- "is-a" and then list thousands of relations ("a flower is a thing") For us, in the atomspace, "is-a" is usually coded as an InheritanceLink

    InheritanceLink

          ConceptNode "flower"

          ConceptNode "thing"

So this uses only two atom types, neither are executable or evaluatable; but if you create thousands of these relations, you get an ontology -- the grand total of all of these thousands of relations is what carries "meaning"; individually, a single atom is more-or-less almost meaningless.

Likewise for "triplestores"/RDF/SparQL --  "Bob knows Fred" could be either

    ListLink

         Concept "knows"

         Concept "Bob"

         Concept "Fred"

or better yet

   EvaluationLink

        PredicateNode "knows"

        ListLink

               Concept "Bob"

               Concept "Fred"

which uses only four atom types grand total, and with these four, you can do anything a triplestore/RDF can do.  And you don't need   cog-execute! and cog-evaluate! for any of this.  So, in this sense,   cog-execute! and cog-evaluate!

are already "advanced topics". 

We are missing some kind of landing page that explain the above -- basic "knowledge representation"  which is mostly what the AtomSpace is supposed to be about.  This basic stuff does not need any of the whizzy atom types, nor the ability to evaluate/execute. --

Basically, this:

https://en.wikipedia.org/wiki/Semantic_network

with worked examples, like the above.

• Atoms are something which "is of some interest" to the user---evaluatable atoms which return bools can be thought of as the "things which (do not) hold in this axiomatic system". But this does not hold for non-evaluatable atoms: indeed, if there is (GreaterThan (Variable "$x") (Number 42)) in the atomspace, it does not mean that all X are greater than 42.

Yes. Variables can be (are) used for several things.  Most importantly, they are used for the query language (see below)

In principle, they can also be used for the knowledge represention of predicate logic.

https://en.wikipedia.org/wiki/Knowledge_representation_and_reasoning

where predicate logic is this:  https://en.wikipedia.org/wiki/First-order_logic

In practice, things get tripped up here. At this time, we do not have any prolog-like engine for the atomspace (we should ... but we don't .. it would not be that hard, I could show you how to take an off-the-shelf reasoner and staple it on; that would be an excellent project!). We do have something called PLN which is prolog-like, but with probabilities, but it has trouble being fast and scaling to reasonable-sized problems.

• The aforementioned link could have been part of something greater, such as (Get (<aforementioned>)).

GetLink is now moving into something more complex -- GetLink is one of the handful of primary, main interfaces to the query language.  So the atomspace is a database. Like any database, it needs a query language -- e.g. SQL, SparQL, etc.

https://en.wikipedia.org/wiki/Query_language

• So, the meaning of all atoms is determined by the user and the way he uses them...?

Yes, more-or-less. Except, by convention, everyone agrees on the meaning of ConceptNode, InheritanceLink and EvaluationLink, etc.  If you use these counter to conventional common-sense, you'll  just confuse everyone.  And other (many) link-types are backed by C++ code that "does something" e.g. GetLink -- If you use that wrong,  an exception will be thrown.

• Or is there something deeper (such as in prolog, where things which are "in the system" are considered "true")?

 Yes, that also.  If this is in the system:

    InheritanceLink

          ConceptNode "flower"

          ConceptNode "thing"

it can be considered to be "true". How can you be sure? Well, every Atom has a TruthValue on it, and you can look at it.  (by default it's true). 

We have several kinds of truth values. One is probabilistic: it records a probability, and a confidence. You can do math with those floats, as you wish.  The truthiness of those numbers is determined by the user and the way they use them.

(you can have vectors of floats ... and more -- json-like structs of values, attached to an atom; up to you what you do with them. They are much smaller and much faster than atoms.)

• Some links seem to either be missing (PartOfLink, ...)

Never seemed important.  You can just say

   EvaluationLink

        PredicateNode "part-of"

        ListLink

               Concept "wheel"

               Concept "car"

The triple-relation is generic, this way.  We made a handful of special-case exceptions e.g. InheritanceLink is semantically the same as

   EvaluationLink

        PredicateNode "is a"

        ListLink

               Concept "flower"

               Concept "thing"

• or their behaviour is not as expected (AbsentLink and PresentLink cannot be cog-evaluated, why?). Maybe something needs to be imported? If so, what? It would be nice to list it in the documentation (wiki).

These are a part of the query language. They don't make much sense outside of the query language.

 

• SatisfyingSetLink: wiki states that
  

   EvaluationLink
     PredicateNode "breathe"
     ListLink
       ConceptNode "animals"
       ConceptNode "air"

  is equivalent to this:
  

   MemberLink
     ListLink
       ConceptNode "animals"
       ConceptNode "air"
     SatisfyingSetLink
       PredicateNode "breathe"

Yes.  However, there is no automatic conversion between the two.

• So I would assume that with either of them, the query (Get (Evaluation (Predicate "breathe") (List (Variable "$x") (Concept "air")))) would return a set containing (Concept "animals").

Yes.

• But in the latter case, it does not.

Because there is no automatic conversion.

• So... the two ways of representing "animals breathe air" are equivalent, but incompatible?

They are "semantically equivalent", they are "syntactically different".  GetLink, and the query language, perform a syntactic search.

Semantics is much harder. Not only might one need to convert between different syntactic forms, but one might also need to chain together syntactic forms -- to do reasoning, inference, deduction, proving, etc. Or even neural nets. Semantics is where things get hard.

• Is it the user's job to use one or the other, or to somehow integrate them if he wants to use them in tandem?
  

Yes.

And other documentation-oriented stuff:

• Scheme interface: cog-bind, cog-satisfy, cog-satisfying-set are either not documented, or obsolete.

The are obsolete.

• But they are still mentioned here and there on the wiki. I suppose the up-to-date way to do these is to do (cog-execute! (Bind ...)), (cog-evaluate! (Satisfaction ...)) and (cog-execute! (Get ...)).

Yes

• Also, many scheme functions were recently removed (such as cog-tv->alist), but they are still in the wiki. I can try clean up what I find.

Yes.

That's it for now.

 Seems like you are well on your way.

-- Linas

[Nil Geisweiller]

On 5/26/19 6:45 PM, Linas Vepstas wrote:
> * SatisfyingSetLink: wiki states that

>
> EvaluationLink
> PredicateNode "breathe"
> ListLink
> ConceptNode "animals"
> ConceptNode "air"
>
> is equivalent to this:
>
> MemberLink
> ListLink
> ConceptNode "animals"
> ConceptNode "air"
> SatisfyingSetLink
> PredicateNode "breathe"
>
> Yes. However, there is no automatic conversion between the two.

There are PLN rules for that, like this (although this one is a bit
convoluted)

https://github.com/opencog/opencog/blob/master/opencog/pln/rules/wip/evaluation-to-member.scm

but yes no automatic way, to do that you need to explicitly run the
rule engine with the appropriate rule base, see

https://wiki.opencog.org/w/Unified_rule_engine

for more details.

Nil

[buj]

Upon further study, I have become quite confused on atomspace's type system. Let me explain:

I was on my quest to understand which links are executable, and which are evaluatable. So I came across various resources: the scheme command cog-get-subtypes, the "type hierarchy definition file" and the "folder where (all) atom types are implemented". I see that the type hierarchy is completely separate from the actual definitions (C++ implementations) of the types, so I assume that it is the user's job to be faithful to the hierachy---if I define a type to be a subtype of EvaluatableLink, then it should be evaluatable, and I (as a programmer) am responsible for implementing this feature. Now, the problem is, a lot of the types do not meet these standards... concretely, there are many subtypes of EvaluatableLink which are not evaluatable (in the cog-evaluate! sense):

• SatisfyingSetLink, MemberLink, SetLink
• some CrispOutputLinks:
• ExistsLink, ForAllLink, PresentLink.
• And also AbsentLink, which is a subtype of PresentLink (why?).

I need to understand why there exists such a disparity. (And also what guarantees the type system provides.) Is it merely because these features were "not in demand"? Or am I missing something bigger/different here? (For many of the links---such as ExistsLink, ForAllLink, PresentLink, AbsentLink---the implementation seems obvious from an outside perspective/at first glance. Though what could possibly "evaluating a SetLink" mean? ...)

[Linas Vepstas]

On Thu, May 30, 2019 at 3:25 PM buj <bujt...@gmail.com> wrote:

Upon further study, I have become quite confused on atomspace's type system. Let me explain:

I was on my quest to understand which links are executable, and which are evaluatable. So I came across various resources: the scheme command cog-get-subtypes, the "type hierarchy definition file" and the "folder where (all) atom types are implemented". I see that the type hierarchy is completely separate from the actual definitions (C++ implementations) of the types, so I assume that it is the user's job to be faithful to the hierachy---if I define a type to be a subtype of EvaluatableLink, then it should be evaluatable, and I (as a programmer) am responsible for implementing this feature.

Yes.

Now, the problem is, a lot of the types do not meet these standards... concretely, there are many subtypes of EvaluatableLink which are not evaluatable (in the cog-evaluate! sense):

• SatisfyingSetLink, MemberLink, SetLink

These do not seem to need C++ classes behind them, because they "don't do anything".

• some CrispOutputLinks:
• ExistsLink, ForAllLink,

These are legacy types; they are not used, at all. No one is implementing the sigma-pi Borel hierarchy in the atomspace. It seemed like a cool idea a decade ago, and they've mouldered ever since. They should probably be removed.

To answer you question more generally: In the beginning, none of the atom types were backed by C++ classes. None, that is, except for Atom, Node and Link. But then BindLink got invented, because it needed to hold a cache of pre-compiled state. So it got a C++ class. And then, one-by-one, reasons were found to add other C++ classes to sit behind certain other atom types. 

Historically, atoms were not "active objects", i.e. did not have methods on them. Other code "did stuff to them" (did stuff with them) It slowly became obvious that it would be better if that external code got migrated into methods on the C++ classes. This is an ongoing, slowly moving project.  Slowly moving, because its not always obvious what the right implementation is.  And its not urgent, since mostly "things work ok as-is".

Based on natural use, there seemed to be some atoms that, when "executed", would naturally return an Atom as a result. Others seemed to naturally return a truth value.  Thus, the distinction between "evaluatable" and "executable".  In the last few years, it became apparent that this distinction is perhaps bogus, so there is another very slow move to erase the distinction.  It cannot be instantly or easily erased, because there are a bunch of theoretical questions, the answer to which are not clear.  Any technical decision like this has side-effects, and its hard to anticipate them. So we grope in the dark, feeling around, trying different designs to see if they feel comfortable or not.

The new wiki page https://wiki.opencog.org/w/AtomSpace#Overview lists 10 bullets in the overview section. The actual C++ code is trying to implement all 10 of them, all at once, even-handedly, without tipping over too far one way or another. Its a hard balancing act.

• PresentLink.
• And also AbsentLink, which is a subtype of PresentLink (why?).

Simpler than having an abstract base class "PresentOrAbsentLink"  Its already hard to explain all of these; creating bogus base classes just further confuses things.

I need to understand why there exists such a disparity. (And also what guarantees the type system provides.)

I hope the above answers your questions.

Is it merely because these features were "not in demand"? Or am I missing something bigger/different here? (For many of the links---such as ExistsLink, ForAllLink,

There is nothing at all obvious about those two. They are good examples of highly non-trivial, non-obvious links. They make delicate statements about the nature of infinity -- or rather, about countable and uncountable infinities, or rather, the infinite number of infinities.

They're not implemented because -- no one is doing set theory in the atomspace;  set theory is a very arcane, obscure and difficult branch of mathematics, and I don't currently see any relevance at all to AI/AGI. Its like topoi, or pointless topology - interesting, certainly, but with no direct bearing that I can see.

Alternately, you could argue that we need ExistsLink, ForAllLink in order to implement first-order-logic, second-order-logic, HOL. or wait .. lets do agda! Another slippery slope.  We do not currently have a functional, crisp-boolean true/false first-order theorem prover for the atomspace. Baby steps .. when someone needs this/wants this .. they can work on it ...

PresentLink, AbsentLink---the implementation seems obvious from an outside perspective/at first glance.

Hah hah. Two weeks ago, I sat down and rolled up my sleeves, and said to myself: "today is the day I implement AbsentLink as a C++ class". It's even mentioned in a comment in a recent commit. After laying the groundwork for this, I realized that it was impossible. Well, maybe not impossible, but very complicated and confusing, to the point that it seemed like a recipe for failure and wasted effort. A classical "bad idea". So I gave up.

 

Though what could possibly "evaluating a SetLink" mean? ...)

Oh!  That's easy! Evaluate all of its members.  I am on the verge of actually implementing that.  I haven't, for two reasons:

1) no one is asking for this. There's no obvious need for it.

2) Different external theories might have their own distinct reason/answer to that question.  For example, PLN states that one should use this-and-such formula to compute the resulting "average" truth value.  But textbook Bayesian probability theory wants to supply you with a similar, but slightly different answer.  And a neural net may want to provide yet another answer ... this is why Values exist (to accommodate all these theories), and it is also why "external code does things with atoms", instead of atoms having methods to do things.  The C++ classes do not have a "Bayesian-probability" method, and a different "neural-net method", etc. ... on down the line.

3) Turns out SetLinks are evil. Who knew? Took years to figure this out, and not everyone understands yet. See the wiki page for SetLinks.

-- Linas

[Nil Geisweiller]

Linas,

On 5/31/19 8:19 AM, Linas Vepstas wrote:
> o ExistsLink, ForAllLink,

>
> These are legacy types; they are not used, at all. No one is
> implementing the sigma-pi Borel hierarchy in the atomspace. It seemed
> like a cool idea a decade ago, and they've mouldered ever since. They
> should probably be removed.

Not so fast, these links are used in PLN, well not in any practical
application ATM, but that should change in the future.

> PresentLink, AbsentLink---the implementation seems obvious from an
> outside perspective/at first glance.
>
>
> Hah hah. Two weeks ago, I sat down and rolled up my sleeves, and said to
> myself: "today is the day I implement AbsentLink as a C++ class". It's
> even mentioned in a comment in a recent commit. After laying the
> groundwork for this, I realized that it was impossible. Well, maybe not

I thought that AbsentLink implementation was nearly complete, and the
PresentLink implementation possibly already complete but requiring
more testing. I am not correct?

I intend to port all my Atomese code to use PresentLink, can I do so
already? I believe I can but your comment is casting some doubt.

Thanks,
Nil

> impossible, but very complicated and confusing, to the point that it
> seemed like a recipe for failure and wasted effort. A classical "bad
> idea". So I gave up.
>
> Though what could possibly "evaluating a SetLink" mean? ...)
>
>
> Oh! That's easy! Evaluate all of its members. I am on the verge of
> actually implementing that. I haven't, for two reasons:
>
> 1) no one is asking for this. There's no obvious need for it.
>
> 2) Different external theories might have their own distinct
> reason/answer to that question. For example, PLN states that one should
> use this-and-such formula to compute the resulting "average" truth
> value. But textbook Bayesian probability theory wants to supply you
> with a similar, but slightly different answer. And a neural net may
> want to provide yet another answer ... this is why Values exist (to
> accommodate all these theories), and it is also why "external code does
> things with atoms", instead of atoms having methods to do things. The
> C++ classes do not have a "Bayesian-probability" method, and a different
> "neural-net method", etc. ... on down the line.
>
> 3) Turns out SetLinks are evil. Who knew? Took years to figure this out,
> and not everyone understands yet. See the wiki page for SetLinks.
>
> -- Linas
>
> --
> cassette tapes - analog TV - film cameras - you
>

> --
> 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
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/CAHrUA3521zp2cKL0ydEhuzb11Rc7JowcuVbPB_AYKW0jnM8vhw%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAHrUA3521zp2cKL0ydEhuzb11Rc7JowcuVbPB_AYKW0jnM8vhw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Linas Vepstas]

On Fri, May 31, 2019 at 12:59 AM 'Nil Geisweiller' via opencog <ope...@googlegroups.com> wrote:

>     PresentLink, AbsentLink---the implementation seems obvious from an
>     outside perspective/at first glance.

I thought that AbsentLink implementation was nearly complete, and the
PresentLink implementation possibly already complete but requiring
more testing. I am not correct?

Both the AbsentLink and PresentLink are fully complete, and work well, with no known bugs.  (I fixed a few bugs a week ago).

There is no C++ class called `class AbsentLink`.  And there probably never will be, because, well, "things just don't work like that".  There is no C++ class called `class PresentLink`, because it would be ... pointless.

I intend to port all my Atomese code to use PresentLink, can I do so
already? I believe I can but your comment is casting some doubt.

Its ready.  PresentLink has been working fine for ...I dunno .. maybe five years already? AbsentLink has been working for ten. Shujing found a bug with AbsentLink, which I fixed recently.  Also, I think (Not (Present ...)) now works correctly, and is the same as absent.

All bets are off if you say (Or (Present x) (Absent y) (Not (And (Absent z) (Not (Or (Present w) (Absent u)))) -- Don't do that. We will hate you if you do.

-- Linas

Thanks,
Nil