I mean, if a pathway is just viewed as a semi-arbitrary set of relationships, then why not just make the pathway a ConceptNode, with MemberLinks to the relationships contained in the pathway? MemberLInks can then have fuzzy weights as needed. I am unsure why we want conjunction semantics here...
-- Ben On Tue, Aug 8, 2017 at 2:11 AM, Ben Goertzel <b...@goertzel.org> wrote: > 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 -- 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/CACYTDBcaW7mBKoSBj_nxYO5--5n9kkDiOXxaQTfyC0sfcknjMQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
