Re: [opencog-dev] PartitionLink, biological pathways, human bodies, etc.

```On Sun, Aug 6, 2017 at 2:09 AM, Nil Geisweiller <ngeis...@googlemail.com>
wrote:```
```
> Linas,
>
> On 08/06/2017 02:12 AM, Linas Vepstas wrote:
>
>> No. I think you're missing the point. Equivalence is normally between
>> pairs of things, and that is very manageable.  You can say a=b and say b=c
>> and then later change your mind about b=c without affecting a=b at all.
>> That is very different than saying {a,b,c} is an equivalence-set.
>>
>> That is, the atomspace is optimized for relations between pairs of
>> things, or maybe triples. quadruple-relations are very rare.  By contrast,
>> sets with hundreds or thousands or millions of members are not uncommon.
>>
>> We are not the first to deal with this.  So both SQL and no noSQL are
>> are both very explicitly be a "relational algebras", and are very
>> explicitly not "set theories". In SQL, the table forms a "set", and it is
>> very easy to add/remove rows in that set. A single row is a relation.  The
>> table of employees has one row per employee. It does NOT have all of the
>> employees jammed into one big giant arbitrary-length row.
>>
>>
>>     (Equivalence (stv 1 1) A (Or B C))
>>     (And (stv 0 1) B C)
>>
>>
>> Both AndLink and OrLink are set-like in their behavior, and this is a
>> problem.  They are not relational, as currently defined.
>>
>
> Regarding set-like-behavior of And and Or, I suppose doing
>
> (And A (And B C))
>
>
> (And A B C)
>
> wouldn't fix it, right?
>

No, because if I decide to drop C, then I have to erase (And B C) and
before I can do that, I have to erase (And A (And B C)) first.

>
> I do sorta feel what you mean about keeping relationships small, but I
> don't concretely understand why its a problem (letting aside that the
> backing store cannot store more than 330 outgoins).
>

Search becomes a problem. Say I want to find (using the pattern matcher)
all sets that contain, as members, A B C. With set notation, I have to
search for (Set X A B C) where X==(VariableNode "X") for 4-elelemnt sets,
and then (Set X Y A B C) for 5-element sets, and so on.  To search all
N-element sets, I can use the GlobeNode G and search for (Set G A B C) ...
and I believe this works correctly today.  However...

However, there's a problem. Sets are UnorderedLinks, and so performing the
search for all six-element sets (Set X Y Z A B C) requires searching 6!=120
permutations. Well, since A B C are fixed, only 6!/3!= 20 permutations have
to be searched. Of the 20, many are duplicates, since (Set X Y Z A B C) ==
(Set Y C X B Z  A)  and so on. The returned results will include all
possible matchups of X Y Z to the other three members -- 3! in all -- so of
the 20 permutations, only 3!=6 are actually different.

For the GlobNode, it would be similar, Now consider a set with 20 elements
-- this requires 20! permutations and 20!=2.4e18 which would be months or
years of CPU time.  Which is absurd.. well, we could stop after finding
exactly one permutation, because that is all we really want... (not sure if
the current glob code does this -- probably not. Man Hin is reworking the
glob code now.).

This is in contrast to the much easier problem of finding all values of X
for which (Member A X) AND (Member B X) AND (Member C X) which can be done
easily and quickly, without requiring permutation exploration.

I don't know, but I suspect that Shujing's Pattern Miner will have trouble
mining patterns for sets, but not for members.   I won't try to give any
PLN arguments, but I suspect that similar considerations apply there.

>
>     I agree about not creating new links up the wazzoo, it must be
>>     carefully thought. However, you don't necessarily need to upgrade
>>     PLN to reason on new links, if you can express the semantics of a
>>     new link as a combination of old links, all you need is to write a
>>     higher order fact such as
>>
>>     EquivalenceScope (stv 1 1)
>>        \$A \$B \$C
>>        Partition \$A (Set \$B \$C)
>>        And
>>          Equivalence \$A (Or \$B \$C)
>>          And \$B \$C
>>
>>     to enable PLN to reason about it.
>>
>>
>> I don't want to argue about it here, but I think that turning everything
>> explicitly into a scope link is a minor mistake.  I think it's just fine to
>> have scoping be implicit.  We don't need to invent a brand new
>> a BlahScopeLink with zero variables. That's all. Don't special-case zero
>> variables as being different from more-than-zero variables.
>>
>
> EquivalenceScope (stv 1 1)
>   <vardecl>
>   P
>   Q
>
> is merely sugar syntax for
>
> Equivalence (stv 1 1)
>   Lambda <vardecl> P
>   Lambda <vardecl> Q
>
> This sugar syntax is mostly useful for humans, because <vardecl> is not
> duplicated in the AtomSpace anyway.
>

Well, but that's not true!  (Scope X   P(X)==Q(X)) is not the same as
(Scope X  P(X)) == (Scope X  Q(X)) because the latter can be
alpha-rewritten as (Scope X  P(X)) == (Scope Y  Q(Y)) which is something
completely different!
-------
But whatever. All I am saying is that we should allow the following form:

EquivalenceScope (stv 1 1)
<empty vardecl>
P
Q

That's all, nothing more.

--linas

> Nil
>
>
>> --linas
>>
>>
>>     Nil
>>
>>
>>         An alternate way of thinking about partitions is as "coloring".
>>         Pick a set, pick N colors, and then insist that every member of
>>         the set must be colored with one of the N colors.  Then coloring
>>         is a lot like partitioning. e.g.
>>
>>                 ColorNode "Red"
>>                 SomeAtom
>>
>>         or maybe
>>
>>                ColorNode "red"
>>                SomeAtom
>>
>>
>>         Color names could, of course, be anything: e.g. the names of the
>>         partitions.
>>
>>         In one sense, colorings are identical to partitions; on the
>>         other hand, they can feel "more general" because you can insist
>>         or demand that certain properties of colorings hold, e.g. ramsey
>>         theory and reverse mathematics.
>>
>>         You could *force* aka gaurantee uniqueness of color assignment
>>
>>                Some Atom
>>                ColorNode "red"
>>
>>         The atomspace automatically gaurantees that one and only one
>>         color can be assigned. (although it can be changed)  The
>>         UniqueLink allows only one assignment, and it cannot be
>>         changed.  These are nice, because they help avoid programmer
>>         error. by offering automatic guarantees.
>>
>>         You don't have to use atoms for this, either. You could use
>>         values.   Recall, values are almost just like atoms, except that
>>         you can't put them into the atomspace, and you cannot
>>         pattern-match or patttern-mine them.   But you can store color
>>         or partition data in values, if you wanted to.  Note that values
>>         *can* hold atoms!  There is a LinkValue that is like a link, but
>>         it can hold atoms or values or a mixture of both.
>>
>>         --linas
>>
>>
>>
>>              This
>>              semantics is implicit in PartitionNode, whereas if you just
>> use
>>              MemberLink you'd need to spell out this "partition"
>>         semantics using a
>>              bunch of AndLinks each time...
>>
>>              As a world-class advocate of the partition function I think
>>         you may
>>              like PartitionNode after you reflect on it infinitesimally
>>         more...
>>
>>              -- ben
>>
>>              On Tue, Aug 1, 2017 at 5:54 AM, Linas Vepstas
>>              <linasveps...@gmail.com <mailto:linasveps...@gmail.com>
>>         <mailto:linasveps...@gmail.com <mailto:linasveps...@gmail.com>>>
>>         wrote:
>>               > Hi Ben, Mike,
>>               >
>>               > On Fri, Jul 21, 2017 at 9:41 PM, Ben Goertzel
>>         <b...@goertzel.org <mailto:b...@goertzel.org>
>>              <mailto:b...@goertzel.org <mailto:b...@goertzel.org>>> wrote:
>>               >>
>>               >> Some interesting representational issues have come up
>>         in the context
>>               >> of Atomspace representation of pathways, which appear
>>         to have more
>>               >> general implications…
>>               >>
>>               >> It seems the semantics we want for a biological pathway
>>         is sort of
>>               >> like “the pathway P is a set of relationships R1, R2,
>>         …, R20” in
>>              kinda
>>               >> the same sense that “the human body is a set of organs:
>>         brain,
>>              heart,
>>               >> lungs, legs, etc.”
>>               >>
>>               >> First of all it seems what we have here is a part of
>>              relationship… maybe
>>               >> we want
>>               >>
>>               >>     ConceptNode “heart”
>>               >>     ConceptNode “human-body”
>>               >>
>>               >> and
>>               >>
>>               >>     >relationship<
>>               >>     >pathway<
>>               >>
>>               >> OpenCog/Novamente/Webmind history...
>>               >>
>>               >> An argument that PartLink should have fundamental
>>         status and a
>>               >> well-defined fuzzy truth value is given in this paper:
>>               >>
>>               >>
>>               >> However what we need for biological pathways and human
>>         bodies seems
>>               >> like a bit more.   We want to say that a human body
>>         consists of a
>>               >> certain set of parts... not just that each of them is a
>>         part...     We're
>>               >> doing a decomposition.
>>               >>
>>               >> One way to do this would be
>>               >>
>>               >>    ConceptNode “human-body”
>>               >>       ConceptNode “legs”
>>               >>       ConceptNode “arms”
>>               >>       ConceptNode “brain”
>>               >>       etc.
>>               >>
>>               >> Relatedly, we could also have
>>               >
>>               >
>>               > As mentioned earlier, there are several problems with this
>>              format.  One is
>>               > the "oops I forgot to mention xyz in the list" or "gosh
>>         I should
>>              have left
>>               > out pqr" and this becomes a big problem:  you have to
>>         delete the
>>              partition.  In the
>>               > meanwhile, some other subsystem might be holding a
>>         handle to the old,
>>               > now-wrong PartitionLink, and there is no effective way of
>>              announcing "hey
>>               > stop using that old thing, get my new thing now".
>>               >
>>               > A second problem is that the above doesn't have anywhere
>>         to hang
>>               > data: e.g. "legs are a big part of the human body,
>>         having a mas
>>              of nearly
>>               > half of the body." You can't just slap that on as a
>>         (truth)value,
>>              cause
>>               > there's no where  to put that value.
>>               >
>>               > Third problem is that large list-links are hard to
>>         handle in the
>>              pattern
>>               > matcher. Its much much harder to write a query of the
>>         form  "find
>>              me all
>>               > values of \$X where
>>               >
>>               >    ConceptNode “human-body”
>>               >       ConceptNode “legs”
>>               >       VariableNode  “\$X”
>>               >       ConceptNode “brain”
>>               >
>>               > because, ... well the ListLink is an ordrerd link, not an
>>               > you forget to include the pqr (added above) then the
>>         search will
>>              fail. You
>>               > could try to use unordered links and globnodes, but
>>              other
>>               > difficulties, including the n! possible permutations of an
>>               > become large n-factorial large when the unordered link
>> has n
>>              items in it.
>>               > Recall that old factorial-70 trick used to make
>>         calculators overflow.
>>               >
>>               > In general, any link with more than 3 or 4 or 5 items in
>>         it is
>>               > This is a generic statement about knowledge
>>         representation in
>>              opencog.
>>               >
>>               >
>>               >>     C
>>               >>     L
>>               >>
>>               >> if we want to encompass cases where the partition
>>         elements in L can
>>               >> overlap; or
>>               >>
>>               >>     C
>>               >>     L
>>               >>
>>               >> if we want to encompass cases where the partition
>>         elements in L can
>>               >> overlap, AND the elements in L may encompass some stuff
>>         that’s
>>              not in
>>               >> C
>>               >>
>>               >> For the pathway case, we could then say
>>               >>
>>               >>     ConceptNode “Krebs cycle”
>>               >>         >relationship 1<
>>               >>         >relationship 2<
>>               >>         etc.
>>               >>
>>               >>
>>               >> Now this solves the semantics problem but doesn’t solve
>> the
>>              problem of
>>               >> having a long ListLink….  A biological pathway might
>>         have 100s or
>>               >> 1000s of relationships in it, and we don't usually want
>>         to make
>>              lists
>>               >> that big in the Atomspace...
>>               >>
>>               >> To solve this we could do something like (for the human
>>         body case)
>>               >>
>>               >>    ConceptNode “human-body”
>>               >>    PartitionNode “body-partition-1”
>>               >>
>>               >>    PartitionNode “body-partition-1"
>>               >>    ConceptNode “legs”
>>               >>
>>               >>    PartitionNode “body-partition-1"
>>               >>    ConceptNode “arms”
>>               >>
>>               >> etc.
>>               >>
>>               >> and similarly (for the biological pathway case)
>>               >>
>>               >>     ConceptNode “Krebs cycle”
>>               >>     PartitionNode “krebs-partition-1”
>>               >>
>>               >>     PartitionNode “krebs-partition-1"
>>               >>     >relationship 1<
>>               >>
>>               >>     PartitionNode “krebs-partition-1”
>>               >>     >relationship 2<
>>               >
>>               >
>>               >
>>               > Yeah, sure. Not sure why the existing MemberLink is not
>>              sufficient for your
>>               > purposes. The MemberLink has reasonably-well-defined
>>         semantics,
>>              there are
>>               > already rules for handling it in PLN (or there will be
>>         rules -- I
>>              think its
>>               > something Nil has thought about)   I'm not clear on why
>>         you'd
>>              want to invent
>>               > something that is just like MemberLink but is different.
>>               >
>>               >>
>>               >>
>>               >> ...
>>               >>
>>               >> There could be some nice truth value math regarding
>>         these, e.g. we
>>               >> could introduce Ellerman's "logical entropy" which is
>>         really a
>>               >> partition entropy.   There are also connections with
>>         some recent
>>               >> theoretical work I've been doing on "graphtropy" (using
>>         "distinction
>>               >> graphs" that generalize partitions), which I'll post a
>>         paper on
>>               >> sometime in the next week or two....   But that will be
>>         another
>>              email
>>               >> for another day...
>>               >
>>               >
>>               > Yeah graphical-entropy is something that I keep trying
>>         to work
>>              on, except
>>               > that every new urgent disaster of the day distracts me
>>         from it.
>>               >
>>               > --linas
>>               >>
>>               >>
>>               >> -- Ben
>>               >>
>>              > --
>>              > You received this message because you are subscribed to
>>              > "opencog" group.
>>              > To unsubscribe from this group and stop receiving emails
>>         from it, send an
>>              > To post to this group, send email to
>> >>.
>>
>>              > Visit this group at
>>              > To view this discussion on the web visit
>>               >
>> TynrThvi%3DrAVa15D-1PSwZpK_37Q%3DjZhcfw%40mail.gmail.com
>> LTynrThvi%3DrAVa15D-1PSwZpK_37Q%3DjZhcfw%40mail.gmail.com>
>> sgid/opencog/CAHrUA35kQx%3DyDcLTynrThvi%3DrAVa15D-1PSwZpK_
>> 37Q%3DjZhcfw%40mail.gmail.com
>> LTynrThvi%3DrAVa15D-1PSwZpK_37Q%3DjZhcfw%40mail.gmail.com>>.
>>              > For more options, visit
>>
>>
>>
>>              --
>>              Ben Goertzel, PhD
>>         http://goertzel.org
>>
>>              "I am God! I am nothing, I'm play, I am freedom, I am life.
>>         I am the
>>              boundary, I am the peak." -- Alexander Scriabin
>>
>>              --
>>              You received this message because you are subscribed to the
>>              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
>>              Visit this group at https://groups.google.com/group/opencog
>>              To view this discussion on the web visit
>> 3DQi%3D_rjJcdrEb5eAmx8ntxffKoRw_dG1OYw%40mail.gmail.com
>> 3DQi%3D_rjJcdrEb5eAmx8ntxffKoRw_dG1OYw%40mail.gmail.com>
>> sgid/opencog/CACYTDBdm6M1y18G%3DQi%3D_rjJcdrEb5eAmx8ntxffKoR
>> w_dG1OYw%40mail.gmail.com
>> 3DQi%3D_rjJcdrEb5eAmx8ntxffKoRw_dG1OYw%40mail.gmail.com>>.
>>              For more options, visit https://groups.google.com/d/optout
>>
>>
>>         --         You received this message because you are subscribed
>> to the
>>         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
>> 4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com
>> b4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com>
>> b4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com?utm_
>> medium=email&utm_source=footer
>> b4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com?utm_
>> medium=email&utm_source=footer>>.
>>         For more options, visit https://groups.google.com/d/optout
>>
>>
>>

--
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