some potentially useful code.

[jac2130]

I've taken it upon myself to rewrite the GO.scm code a bit: At first I ended up with this: https://github.com/jac2130/obo_to_Atom_Space But then I found a wonderful little toolbox for ontologies, called pronto and then, after making a few adjustments to that library in my own fork (https://github.com/jac2130/pronto) and after realizing that much work has been done on opencog tools, I came up with this: https://github.com/CollectiWise/collectiwise/blob/master/python/scheme_router.py combined with these statements, directly in Scheme Atomese: https://github.com/CollectiWise/collectiwise/blob/master/statements.scm Now, you'll notice that they are very incomplete at the moment but the idea to send statements and relationship types directly as a json stream through a router to the AtomSpace is what drove me to this, because I'm building a live ontology and crowd reasoning system that may be updated in real time. The nice ideas embodied in the pronto library are quite helpful. The pronto library allows for easy ontology merging, taking either owl or obo ontologies and it links information in intuitive and powerful ways. So the idea then is to push as much of the work as possible to the ontology library (pronto) and to the Scheme file in which the statements are crafted, leaving a thin message router that just takes an ontology as input and sends terms and relationships to the appropriate scheme functions, written in scheme code and feeding the results directly into the AtomSpace (no need for files). I will add to this that non-ontological logical statements (implications etc) can also be sent through this router via JSON. This will lead to a detailed logical semantics of the ontological relationships in some set of ontologies (in my case it will be the set of relations which are found in the ENVO and the SDGIO (https://github.com/SDG-InterfaceOntology/sdgio) ontologies. No matter what ontologies or lists of logical statements (axioms) you will use, the number of types of relations is rather small, even in huge ontologies or knowledge bases, because they are just the set of rules by which things can be ontologically or logically related. These relationships, in turn, have an even smaller set of properties (is_symmetric, is_transitive etc. , for an exhaustive list of obo defined relationship properties, see here: https://metacpan.org/pod/OBO::Core::RelationshipType#is_cyclic) the meanings of which I will encode precisely in Scheme Atomese next. Currently, pronto only picks up a handful of those relationship properties but I will work on that as well. Further improvements and additional features are planned. While this code is part of a bigger project, I think it could be useful pretty quickly for the things that you are doing here and maybe you could provide me with some feedback and ideas as to how to encode things in Atomese in the process? I hope that it turns out to be useful for someone aside from me and my team!

[linas]

Cool!

Some quibbles about terminology. The AtomSpace is a "knowledge store"; you stick data into it, the data forms graphs. Some of these graphs can be "expression trees" - https://en.wikipedia.org/wiki/Binary_expression_tree -- So, whenever your knowledge graph is also a expression tree, we call it "Atomese" (we can store things far more general than whats in the wikipedia article) . Soooo - the atomspace can not only store expression trees, but it can also run & execute them. That means that many "knowledge graphs" just happen to also be "executable programs", and so whenever you poke some data into the atomspace, you might also be "writing a program" (whether its actually a "program" depends on what you actually did, but whatever).

So that means that -- data stored in the atomspace also looks like a programming language, and we call that "atomese". Its got nothing to do with scheme. Or python. (or C++ or haskell...) You can write atomese in python ... or scheme .. or c++ .. whatever.

Note also that atomese has no scheme in it - it has no python in it. It has no C++ in it. Its just the abstract graph that also just happens to be executable.

Note also that atomese is not really "meant for humans", its really meant to make it easy for algos to edit graphs and do funky things with them. (e.g. like creating and editing the expression tree from the wikipedia article.)

There;s a pile of examples here: https://github.com/opencog/atomspace/tree/master/examples/atomspace

[jac2130]

Cool!

Some quibbles about terminology. The AtomSpace is a "knowledge store"; you stick data into it, the data forms graphs. Some of these graphs can be "expression trees" - https://en.wikipedia.org/wiki/Binary_expression_tree -- So, whenever your knowledge graph is also a expression tree, we call it "Atomese" (we can store things far more general than whats in the wikipedia article) . Soooo - the atomspace can not only store expression trees, but it can also run & execute them. That means that many "knowledge graphs" just happen to also be "executable programs", and so whenever you poke some data into the atomspace, you might also be "writing a program" (whether its actually a "program" depends on what you actually did, but whatever).

So that means that -- data stored in the atomspace also looks like a programming language, and we call that "atomese". Its got nothing to do with scheme. Or python. (or C++ or haskell...) You can write atomese in python ... or scheme .. or c++ .. whatever.

Note also that atomese has no scheme in it - it has no python in it. It has no C++ in it. Its just the abstract graph that also just happens to be executable.

Note also that atomese is not really "meant for humans", its really meant to make it easy for algos to edit graphs and do funky things with them. (e.g. like creating and editing the expression tree from the wikipedia article.)

There;s a pile of examples here: https://github.com/opencog/atomspace/tree/master/examples/atomspace

Hi Linas, That all makes sense to me for sure. I'd like to build essentially build a point of communication between humans and the AtomSpace so that a group intelligence may emerge. It would be incredible if you could give lectures about what can be done and what kind of reasoning can be performed and how that might be made social, so that reasoning can be split between human reasoning and machine reasoning so as to achieve better and better complementarity. The full contextualized meaning of relationships (such as marriage) may then emerge from this machine-human dialogue, which I envision as a game. We soon will have a prototype and we'd appreciate your guidance!

Johannes

[linas]

Hi @jac2130 so... various points:

• This repo is devoted to genomics, proteomics and biology, and so isn't quite the right forum for a more general discussion.
• I talked briefly about reasoning in a different thread on the mailing list. I have avoided think much about reasoning; I plan to dive deeply into it "real soon now".
• The AtomSpace and OpenCog are related but different things. The AtomSpace is a persistent, distributed graph database with a query processor and more. It is meant to hold graphs, and represent them in such a way that various graph processing algorithms can easily work with them: create them, edit them, shrink/grow/modify them, whatever.
• So the AtomSpace is meant to "store knowledge", to be a knowledgebase.
• The "human" interface is the interface to the algorithm(s) that work in, work on the knowledgebase. The human interface might be a system where you ask a question, and get an answer. (say, in "plain english").. Or maybe you pose some common-sense reasoning riddles, and get an answer.
• So, of course, you can "program in Atomese", if you really want to. But its like programming in SQL, or programming in assembler. People who need to get certain things done (compiler, linker, loader, c-library) are excellent assembler programmers. But assembly is "not for humans"; use a high-level language instead.
• Atomese is a mashup of assembly code and SQL. Literally. I don't mean this figuratively, I mean, for real, literally. Think of Atomese as a whack kind of bytecode, like java bytecode. But for data. And currently 1000 times slower.
• There are as many ways of representing data in Atomese as there are ways of writing programs. You are limited by your imagination. Of course, some ways work better than others, which is why I was recommending going through all of the examples.
• I can try to help with the reasoning thing; I plan to eventually make it my #1 priority, just not this week/month.

[linas]

Here: read and contemplate this: https://en.wikipedia.org/wiki/Common_Intermediate_Language and now think "how would I do the same thing, but for a database? How would I represent atomic data, instead of atomic procedures? Reasoning by analogy: If CIL bytecode is for procedural programming, then what kind of bytecode would one have for declarative programming?"

I tried to answer these questions, and the answer I got was "Atomese". So, here, for example, from the wikipedia article:

.class public Foo
{
    .method public static int32 Add(int32, int32) cil managed
    {
        .maxstack 2
        ldarg.0 // load the first argument;
        ldarg.1 // load the second argument;
        add     // add them;
        ret     // return the result;
    }
}

The above tells the CIL virtual machine (VM) to add two numbers together. I'm interestted in something else: describing that something is a additive relationship between two numbers. Or this:

.class public Car
{
    .method public specialname rtspecialname instance void .ctor(int32, int32) cil managed
    {
        /* Constructor */
    }

    .method public void Move(int32) cil managed
    {
        /* Omitting implementation */
    }

    .method public void TurnRight() cil managed
    {
        /* Omitting implementation */
    }

    .method public void TurnLeft() cil managed
    {
        /* Omitting implementation */
    }

    .method public void Brake() cil managed
    {
        /* Omitting implementation */
    }
}

The above is a set of commands for telling the CIL VM to drive a car around. I'm more interesting in describing a car, in terms of what it can do: go forward, turn, brake. I would use CIL if I could, but I can't: CIL, and Java bytecode, and gnu lightning, etc. are all procedural, whereas data is always declarative. Thus: Atomese is a declarative "bytecode", for describing data, instead of describing procedures.

[jac2130]

Cool!

Some quibbles about terminology. The AtomSpace is a "knowledge store"; you stick data into it, the data forms graphs. Some of these graphs can be "expression trees" - https://en.wikipedia.org/wiki/Binary_expression_tree -- So, whenever your knowledge graph is also a expression tree, we call it "Atomese" (we can store things far more general than whats in the wikipedia article) . Soooo - the atomspace can not only store expression trees, but it can also run & execute them. That means that many "knowledge graphs" just happen to also be "executable programs", and so whenever you poke some data into the atomspace, you might also be "writing a program" (whether its actually a "program" depends on what you actually did, but whatever).

So that means that -- data stored in the atomspace also looks like a programming language, and we call that "atomese". Its got nothing to do with scheme. Or python. (or C++ or haskell...) You can write atomese in python ... or scheme .. or c++ .. whatever.

Note also that atomese has no scheme in it - it has no python in it. It has no C++ in it. Its just the abstract graph that also just happens to be executable.

Note also that atomese is not really "meant for humans", its really meant to make it easy for algos to edit graphs and do funky things with them. (e.g. like creating and editing the expression tree from the wikipedia article.)

There;s a pile of examples here: https://github.com/opencog/atomspace/tree/master/examples/atomspace

Hi Linas, That all makes sense to me for sure. I'd like to build essentially build a point of communication between humans and the AtomSpace so that a group intelligence may emerge. It would be incredible if you could give lectures about what can be done and what kind of reasoning can be performed and how that might be made social, so that reasoning can be split between human reasoning and machine reasoning so as to achieve better and better complementarity. The full contextualized meaning of relationships (such as marriage) may then emerge from this machine-human dialogue, which I envision as a game. We soon will have a prototype and we'd appreciate your guidance!

Johannes