Yes! On Fri, Aug 4, 2017 at 4:07 PM, 'Nil Geisweiller' via opencog <[email protected]> wrote: > 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 >> <[email protected] <mailto:[email protected]>> wrote: >> > Hi Ben, Mike, >> > >> > On Fri, Jul 21, 2017 at 9:41 PM, Ben Goertzel <[email protected] >> <mailto:[email protected]>> 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> >> >> >> >> 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 [email protected] >> <mailto:opencog%[email protected]>. >> > To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> > 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/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>. >> >> >> >> -- >> 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 [email protected] >> <mailto:opencog%[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> 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/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>. >> >> >> -- >> 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 [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> 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/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>. >> 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 to [email protected]. > To post to this group, send email to [email protected]. > 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/8aa12595-28a0-f983-be51-db8c8d3719c3%40gmail.com. > > For more options, visit 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 [email protected]. To post to this group, send email to [email protected]. 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/CACYTDBeHhSQV4pznH1-bd4Gry6vQYC8ES%3DjBY-hbpODnTw%2BeLg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
