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

[Michael Duncan]

i actually think an AndLink-like semantics better fits biochemical pathways 
at a computationally tractable level than partitions in that below the 
level of a whole organism, where one pathway ends and another begins is 
largely arbitrary.  also,  if one link is missing then the whole thing 
doesn't work but the last bit of a dead end might be the start of another 
path that goes to the same place, more like words and phrases that can be 
rearranged and swapped in different ways to say the same thing.  linus idea 
of AndMemberLinks and OrMemeberLinks would get around the size limitation 
and also seem like they would be useful for reasoning on moses models.

On Monday, July 31, 2017 at 5:55:16 PM UTC-4, linas wrote:
>
> Hi Ben, Mike,
>
> On Fri, Jul 21, 2017 at 9:41 PM, Ben Goertzel  > 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
>>
>> 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
>>

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

['Nil Geisweiller' via opencog]

On 08/03/2017 10:06 AM, Linas Vepstas wrote:
There's also a problem of editing: what if, half-way through, you want 
to change the partition? Can you? should you? should users instead be 
told that a partition, once-created, is immutable, so you can only 
create and destroy them?


But isn't the same true for almost any link?

(Equivalence (stv 1 1) A (Or B C))
(And (stv 0 1) B C)

is immutable too, and could be equivalent to

(Partition (stv 1 1) A (Set B C))

saying that A is partitioned into block B and C.



Do you truly need a partition link? I mean -  I invent new link types 
all the time, since that's usually pretty cheap. But I also do not 
expect my new link types to work with PLN. In this case, don't you want 
pln interop?


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.

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
> wrote:
 > Hi Ben, Mike,
 >
 > On Fri, Jul 21, 2017 at 9:41 PM, Ben Goertzel > 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

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