I don't understand the proposed semantics of AndMemberLink, could you explain?
On Sat, Aug 5, 2017 at 1:07 AM, Michael Duncan <mjsdun...@gmail.com> wrote: > 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 <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 >>> >>> 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. > 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/e1df7273-da14-45f5-8d0d-5ebad0d31217%40googlegroups.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 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/CACYTDBe2gXG6ZNT-kD%3DWp-0jW4%2BxEkknsKk0Le559SkfMj5EWQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
