On Fri, Jul 23, 2021 at 7:44 AM Ivan V. <[email protected]> wrote:
> Knowing that new Atomspace versions may be coming, I'd like to leave the > support option open. > I do not expect any "new AtomSpace versions". I believe that the mentioned JSON input would work well enough with the > incoming versions. > I understand you were talking abbott JSON in a different context, but there has been enough general confusion (with other correspondents) that I recently added a "what the AtomSpace is not" section to the main README. One of the things it says is "the AtomSpace is not JSON". I think it might be educational to review this. cut-n-pste below. What it isn't Newcomers often struggle with the AtomSpace, because they bring preconceived notions of what they think it should be, and its not that. So, a few things it is not. - *Its not JSON.* So JSON is a perfectly good way of representing structured data. JSON records data as key:value pairs, arranged hierarchically, with braces, or as lists, with square brackets. The AtomSpace is similar, except that there are no keys! The AtomSpace still organizes data hierarchically, and provides lists, but all entries are anonymous, nameless. Why? There are performance (CPU and RAM usage) and other design tradeoffs in not using explicit named keys in the data structure. You can still have named values; it is just that they are not required. There are several different ways of importing JSON data into the AtomSpace. If your mental model of "data" is JSON, then you will be confused by the AtomSpace. - *It's not SQL. It's also not noSQL*. Databases from 50 years ago organized structured data into tables, where the key is the label of a column, and different values sit in different rows. This is more efficient than JSON, if you have many rows: you don't have to store the same key over and over again, for each row. Of course, tabular data is impractical if you have zillions of tables, each with only one or two rows. That's one reason why JSON was invented. The AtomSpace was designed to store *unstructured* data. You can still store structured data in it; there are several different ways of importing tabular data into the AtomSpace. If your mental model of "data" is structured data, then you will be confused by the AtomSpace. - *It's not a vertex+edge store*. (Almost?) all graph databases decompose graphs into lists of vertexes and edges. This is just fine, if you don't use complex algorithms. The problem with this storage format is locality: graph traversal becomes a game of repeatedly looking up a specific vertex and then, a specific edge, each located in a large table of vertexes and edges. This is non-local; it requires large indexes on those tables (requires a lot of RAM), and the lookups are CPU consuming. Graph traversal can be a bottleneck. The AtomSpace avoids much of this overhead by using (hyper-/meta-)graphs. This enables more effective and simpler traversal algorithms, which in turn allows more sophisticated search features to be implemented. If your mental model of graph data is lists of vertexes and edges, then you will be confused by the AtomSpace. The actual AtomSpace resembles some aspects of all three, without being specifically any of them. It tries to be general: it wants to let you work with structured data or with unstructured data or with graphs, or any mixture of all three, however you please. It does not force any particular style. You can store data as ontologies, or as lambda expressions, or as prolog-like logical statements, or as syntactic (BNF-style) productions or as constraints or as RDF/OWL style schemas ... you can mix declarative, procedural and functional styles ... we don't care. The AtomSpace is meant to allow general knowledge representation, in any format. That said: it means that the AtomSpace is different and unusual. It might be a bit outside of the comfort zone for most programmers. It doesn't have API's that are instantly recognizable to users of these other systems. There is a challenging learning curve involved, here. We're sorry about that: if you have ideas for better API's that would allow the AtomSpace to look more conventional, and be less intimidating to most programmers, then contact us! > > peace, > ivan > > čet, 22. srp 2021. u 00:09 Michael Duncan <[email protected]> napisao > je: > >> this is very cool, ivan! two suggestions would be to indicate on the >> ovals with a tick mark where the off-screen nodes are to guide navigation, >> and a permanent slider/[+,-] buttons for global zoom control. (i know >> these are obvious) >> >> On Tuesday, July 13, 2021 at 7:15:09 AM UTC-4 [email protected] wrote: >> >>> While waiting for inference histories, I'm developing an idea about >>> turning the inference visualizer into an interactive AtomSpace debugger: >>> http://ocog.atspace.cc/. >>> >>> pon, 12. srp 2021. u 21:43 Ivan V. <[email protected]> napisao je: >>> >>>> Great, I'm glad you are interested in an experiment. >>>> >>>> A reasonable step would be for Nil to send you some real PLN and URE >>>>> inference histories and see what your visualizer does with them... >>>>> >>>> >>>> Sure, JSON history files would be perfect (we could make this a >>>> standard communication pipe between reasoner and visualizer), but I guess I >>>> can somehow manage any existing format you are already used to. You know my >>>> mail. >>>> >>>> Currently, the library is AJAX-ing an XML tree structure and standard >>>> HTMLs as input, with possibility of using php or other server side >>>> scripting technology to interface the input files you pass over here. Would >>>> that be ok? I have to mention, with some additional effort, there could be >>>> other input options such as reading and evaluating JSON file wrapped into >>>> javascript source code file. I'm telling this because this would exclude >>>> the requirement of running a HTTP and php server, but if it is not >>>> necessary, I'd like to avoid this step and do the php trick. >>>> >>>> pon, 12. srp 2021. u 20:30 Ben Goertzel <[email protected]> napisao je: >>>> >>>>> A reasonable step would be for Nil to send you some real PLN and URE >>>>> inference histories and see what your visualizer does with them... >>>>> >>>>> On Mon, Jul 12, 2021, 10:59 AM Ivan V. <[email protected]> wrote: >>>>> >>>>>> I made a small infinity test <http://ocog.atspace.cc/infinite/> too. >>>>>> Each parent virtually has an infinite number of children. Rolling ovals >>>>>> around, zooming ovals in, zooming ovals out, ... Surely it's not exactly >>>>>> perfect, but I could live with it. >>>>>> >>>>>> pon, 12. srp 2021. u 17:48 Linas Vepstas <[email protected]> >>>>>> napisao je: >>>>>> >>>>>>> Hi Ivan, >>>>>>> >>>>>>> On Mon, Jul 12, 2021 at 6:00 AM Ivan V. <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> Thank you for asking, and my thoughts are pretty obvious. As I >>>>>>>> understand, URE and PLN are all about proofs, so my thoughts may go in >>>>>>>> that >>>>>>>> direction. Suppose we have a natural deduction proof composition: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * --- --- --- --- --- --- --- --- --- I >>>>>>>> J K L M N P Q R ----------------- >>>>>>>> ----------------- ----------------- A B >>>>>>>> C----------------------------------------------------------- >>>>>>>> X* >>>>>>>> >>>>>>>> You can already see the tree-like composition, but as it may span >>>>>>>> over a very wide and tall area, it may be required to represent it >>>>>>>> within >>>>>>>> an on-demand scaling system. This example <http://ocog.atspace.cc/> >>>>>>>> roughly shows what I have imagined for proof representation. In the >>>>>>>> example >>>>>>>> you can play with ovals, dragging them around and in or out the central >>>>>>>> area, zooming proof parts of the current interest. Notice how it is >>>>>>>> possible to represent and navigate nearly infinite length proofs, >>>>>>>> assuming >>>>>>>> enough memory space. >>>>>>>> >>>>>>> >>>>>>> Re: navigating trees: if you don't already know this, then I suggest >>>>>>> that you really, really should study hyperbolic rotations aka mobius >>>>>>> transformations on the poincare disk. They implement your example. I >>>>>>> recall seeing a demo of this at SIGGRAPH two or three decades ago. As >>>>>>> you >>>>>>> pan around on the hyperbolic disk, different parts of the graph get >>>>>>> magnified at the center. And, like an MC Escher print, the rest of the >>>>>>> graph remains compressed at the edges. >>>>>>> >>>>>>> For scale-free networks, this doesn't work. And from what I can >>>>>>> tell, learning really does result in something close to scale-free >>>>>>> networks. What this means in practice is that there's one vertex with a >>>>>>> million edges coming off of it. There are two, with half-a-million >>>>>>> each. >>>>>>> Four, with a quarter-million each, and so on. So almost all vertexes >>>>>>> have >>>>>>> just a handful of edges connected to them, but as you move around, from >>>>>>> vertex to vertex, you bump into these monsters. And you can't really >>>>>>> draw >>>>>>> them: try drawing a vertex with a thousand edges on your 2Kx2K monitor: >>>>>>> most of those edges will be less than one pixel from each-other. It'll >>>>>>> be >>>>>>> just a big blob. >>>>>>> >>>>>>> It's important to "eat your own dog-food", as they say, or "smoke >>>>>>> your own dope": use your own code to solve actual, real-world problems. >>>>>>> This very quickly highlights where all that beautiful theory doesn't >>>>>>> quite >>>>>>> work out in practice. >>>>>>> >>>>>>> --linas >>>>>>> >>>>>>> -- >>>>>>> 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/CAHrUA34HBqa02JkW9-EVR5OrpSkOWEMGjZBOCPM2vKKpJR2%2B0A%40mail.gmail.com >>>>>>> <https://groups.google.com/d/msgid/opencog/CAHrUA34HBqa02JkW9-EVR5OrpSkOWEMGjZBOCPM2vKKpJR2%2B0A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> 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/CAB5%3Dj6UgLR5xMP9WeE%2BWOkqBynGTr%2BNQTwsmUq9JrSuU1Sh1ZA%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UgLR5xMP9WeE%2BWOkqBynGTr%2BNQTwsmUq9JrSuU1Sh1ZA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> 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/CACYTDBeOoqMRD20KFDYPGG1YfRqT0qW4wehOGtTKSqTb%3D6L2Jw%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/opencog/CACYTDBeOoqMRD20KFDYPGG1YfRqT0qW4wehOGtTKSqTb%3D6L2Jw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> 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/88dc6d00-07a3-4421-9cc0-9e5e1a8d0052n%40googlegroups.com >> <https://groups.google.com/d/msgid/opencog/88dc6d00-07a3-4421-9cc0-9e5e1a8d0052n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAB5%3Dj6UWpdQOir0eZ2Xj%2B8rYW1s6DtCurK%2BvJ9qa2WoxL61MVg%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UWpdQOir0eZ2Xj%2B8rYW1s6DtCurK%2BvJ9qa2WoxL61MVg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. -- 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/CAHrUA36YHyy_aYCAHv6nq%3Dk%2BLhkJPpbaWBV5U%2BQg%2BgncXy_U7g%40mail.gmail.com.
