Hi,
Good questions!
On Sat, May 25, 2019 at 6:09 PM buj <bujtuc...@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
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CAHrUA34fKhY3Bxnckjh%3DApbUpRvbb-oQYadkHuJ6tX0joBRhNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
