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

instead of

(And A B C)

wouldn't fix it, right?

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

    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 BlahScopeLink for each and every BlahLink. Just pretend that BlahLink is 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.

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.

        ColorLink
                ColorNode "Red"
                SomeAtom

        or maybe

        EvaluationLink
               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
        by using a StateLink:

        StateLink
               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
              >>
              >> PartLink
              >>     ConceptNode “heart”
              >>     ConceptNode “human-body”
              >>
              >> and
              >>
              >> PartLink
              >>     >relationship<
              >>     >pathway<
              >>
              >> PartLink and PartOfLink have come and gone in
              >> OpenCog/Novamente/Webmind history...
              >>
              >> An argument that PartLink should have fundamental
        status and a
              >> well-defined fuzzy truth value is given in this paper:
              >>
              >> https://www.academia.edu/1016959/Fuzzy_mereology
        <https://www.academia.edu/1016959/Fuzzy_mereology>
             <https://www.academia.edu/1016959/Fuzzy_mereology
        <https://www.academia.edu/1016959/Fuzzy_mereology>>
              >>
              >> 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
              >>
              >> PartitionLink
              >>    ConceptNode “human-body”
              >>    ListLink
              >>       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
              > PartitionLink, delete the ListLink, create a new list and
             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
             addtional
              > 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
              >
              > PartitionLink
              >    ConceptNode “human-body”
              >    ListLink
              >       ConceptNode “legs”
              >       VariableNode  “$X”
              >       ConceptNode “brain”
              >
              > because, ... well the ListLink is an ordrerd link, not an
             unordered link. If
              > you forget to include the pqr (added above) then the
        search will
             fail. You
              > could try to use unordered links and globnodes, but
        these lead to
             other
              > difficulties, including the n! possible permutations of an
             unordered link
              > 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
             bad news.
              > This is a generic statement about knowledge
        representation in
             opencog.
              >
              >
              >> OverlappingPartitionLink
              >>     C
              >>     L
              >>
              >> if we want to encompass cases where the partition
        elements in L can
              >> overlap; or
              >>
              >> CoveringLink
              >>     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
              >>
              >> PartitionLink
              >>     ConceptNode “Krebs cycle”
              >>     ListLink
              >>         >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)
              >>
              >> PartitionLink
              >>    ConceptNode “human-body”
              >>    PartitionNode “body-partition-1”
              >>
              >> PartitionElementLink
              >>    PartitionNode “body-partition-1"
              >>    ConceptNode “legs”
              >>
              >> PartitionElementLink
              >>    PartitionNode “body-partition-1"
              >>    ConceptNode “arms”
              >>
              >> etc.
              >>
              >> and similarly (for the biological pathway case)
              >>
              >> PartitionLink
              >>     ConceptNode “Krebs cycle”
              >>     PartitionNode “krebs-partition-1”
              >>
              >> PartitionElementLink
              >>     PartitionNode “krebs-partition-1"
              >>     >relationship 1<
              >>
              >> PartitionElementLink
              >>     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
        the Google Groups
             > "opencog" group.
             > To unsubscribe from this group and stop receiving emails
        from it, send an
             > email to opencog+unsubscr...@googlegroups.com
        <mailto:opencog%2bunsubscr...@googlegroups.com>
             <mailto:opencog%2bunsubscr...@googlegroups.com
        <mailto:opencog%252bunsubscr...@googlegroups.com>>.
             > To post to this group, send email to
        opencog@googlegroups.com <mailto:opencog@googlegroups.com>
        <mailto:opencog@googlegroups.com <mailto:opencog@googlegroups.com>>.
             > Visit this group at
        https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>
             <https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>>.
             > To view this discussion on the web visit
              >
        
https://groups.google.com/d/msgid/opencog/CAHrUA35kQx%3DyDcLTynrThvi%3DrAVa15D-1PSwZpK_37Q%3DjZhcfw%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CAHrUA35kQx%3DyDcLTynrThvi%3DrAVa15D-1PSwZpK_37Q%3DjZhcfw%40mail.gmail.com>
<https://groups.google.com/d/msgid/opencog/CAHrUA35kQx%3DyDcLTynrThvi%3DrAVa15D-1PSwZpK_37Q%3DjZhcfw%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CAHrUA35kQx%3DyDcLTynrThvi%3DrAVa15D-1PSwZpK_37Q%3DjZhcfw%40mail.gmail.com>>.
             > For more options, visit
        https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>
        <https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>>.



             --
             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
        Google
             Groups "opencog" group.
             To unsubscribe from this group and stop receiving emails
        from it,
             send an email to opencog+unsubscr...@googlegroups.com
        <mailto:opencog%2bunsubscr...@googlegroups.com>
             <mailto:opencog%2bunsubscr...@googlegroups.com
        <mailto:opencog%252bunsubscr...@googlegroups.com>>.
             To post to this group, send email to
        opencog@googlegroups.com <mailto:opencog@googlegroups.com>
             <mailto:opencog@googlegroups.com
        <mailto:opencog@googlegroups.com>>.
             Visit this group at https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>
             <https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>>.
             To view this discussion on the web visit
        
https://groups.google.com/d/msgid/opencog/CACYTDBdm6M1y18G%3DQi%3D_rjJcdrEb5eAmx8ntxffKoRw_dG1OYw%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CACYTDBdm6M1y18G%3DQi%3D_rjJcdrEb5eAmx8ntxffKoRw_dG1OYw%40mail.gmail.com>
<https://groups.google.com/d/msgid/opencog/CACYTDBdm6M1y18G%3DQi%3D_rjJcdrEb5eAmx8ntxffKoRw_dG1OYw%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CACYTDBdm6M1y18G%3DQi%3D_rjJcdrEb5eAmx8ntxffKoRw_dG1OYw%40mail.gmail.com>>.
             For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>
             <https://groups.google.com/d/optout
        <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 to opencog+unsubscr...@googlegroups.com
        <mailto:opencog%2bunsubscr...@googlegroups.com>
        <mailto:opencog+unsubscr...@googlegroups.com
        <mailto:opencog%2bunsubscr...@googlegroups.com>>.
        To post to this group, send email to opencog@googlegroups.com
        <mailto:opencog@googlegroups.com>
        <mailto:opencog@googlegroups.com <mailto:opencog@googlegroups.com>>.
        Visit this group at https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>.
        To view this discussion on the web visit
        
https://groups.google.com/d/msgid/opencog/CAHrUA34XVDQHNeYjb4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CAHrUA34XVDQHNeYjb4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com>
        
<https://groups.google.com/d/msgid/opencog/CAHrUA34XVDQHNeYjb4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com?utm_medium=email&utm_source=footer
        
<https://groups.google.com/d/msgid/opencog/CAHrUA34XVDQHNeYjb4r9eFjmrZxN%3DfNmE6wDQTV%2B__cJpEF3qw%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
        For more options, visit https://groups.google.com/d/optout
        <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 
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/5e4def32-4e70-cb9c-b2f5-30c5e70851da%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to