Linas, > So .. hypergraphs really are different than graphs, in some important ways. > The graph-algorithm people struggle to find "chunky" pieces, because they are > limited to just ... vertexes and edges. We've got something ... better. > Hypergraphs have "natural chunks". Given an atom X, the corresponding natural > chunk is the entire, recursive incoming set of X. > > It's worth dwelling on this point for a moment. For an ordinary graph, given > a vertex V, it is tempting to define a "natural chunk" as V plus all the > edges E attached to it. But then one has the overwhelming urge to make it > just a tiny bit larger ... by also adding those edges that would form > complete triangles. If one succumbs to this urge, then, heck, lets include > those edges that make squares, or maybe instead, if an edge is attached to a > dense hub, then include that hub and spokes as well... all of a sudden, it > snowballs out of control, and the simple idea of a "natural chunk" in a graph > is not natural at all, it's just some snowball of things that were deemed > "well-connected-enough". > > Somehow, hypergraphs chunks don't succumb to this temptation. The incoming > set is very natural, and I can't think of any particular way that I would > want to make it "larger". I can't think of any heuristic, rule-of-thumb, > common-sense idea to make it larger. So it really feels natural, it's > resistant to snowballing, it's endowed with a naturalness property that > ordinary graphs don't have. ... and that's a good thing. We can come back > to this, but it seems reasonable to set aside the chunking problem for now.
Hmm... you are right that OpenCog hypergraphs have natural chunks defined by recursive incoming sets. However, I think these chunks are going to be too small, in most real-life Atomspaces, to serve the purpose of chunking for a distributed Atomspace I.e. it is true that in most cases the recursive incoming set of an Atom should all be in the same chunk. But I think we will probably need to deal with chunks that are larger than the recursive incoming set of a single Atom, in very many cases. > * Peer networks. The idea here is that (if) no one has the full dataset, but > everyone has some part of it. Suppose you want some portion of it. Suppose > that the portion you want can be described by a BindLink. You then look (in > dht/ipfs) to see which peers in the network have recent results for that > bindlink (i.e. they ran it recently, they've got hot, recent results cached). > You then contact those peers (at cog://example.com/ using the existing > cogserver) to get those results. It is up to you to merge them all together > (deduplicate). And then you would announce "hey I've recently run this > bindlink, I've got cached results, in case anyone cares" (this is all > automated under the covers). This relates to the idea that results from a BindLink query should be a chunk, right? > It's possible that none of the peers on the network have recent results for > the bindlink. In which case, you have to ask them "oh pretty please can you > run this query for me?" -- you ask because some might refuse to, because they > may be overloaded. e.g. they may be willing to serve up incoming-sets, but > not bindlinks. You can then punt, or you can ask for the incoming sets if you > think you don't have everything you need. > > I'm glossing over details, but I think all this is quite doable, and just not > that hard. What happens when the results for that (new) BindLink query are spread among multiple peers on the network in some complex way? > > See where I'm going with this? I'm basically saying "let's prototype some of > these basics, and use them in an actual project, and see how it goes". The genomics use-case is a good one for this, and I think we could come up with some further details for you on what we want from a distributed Atomspace for a genomic data service. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBe4NFB3AiGHp3omQQXum25GjxaXGoL5%3DZQYK2qEXfRMuA%40mail.gmail.com.
