using opencog to improve AI answers to SAT analogy questions?

Johannes Castner

unread,

Feb 20, 2019, 7:25:11 AM2/20/19

to opencog

Hi everyone,

I think I might want to try to improve on the solution below using opencog in some way. In particular, maybe the solution could be improved by first inferring some connections between ideas that are not represented in ConceptNet, from the ConceptNet data -- things that are likely also true but that are not expressed and then doing the embeddings on the more complete graph. Any thoughts? How does one get to more metaphorical and less explicit knowledge? I find this endlessly fascinating!

http://blog.conceptnet.io/posts/2016/conceptnet-5-5-and-conceptnet-io/

Linas Vepstas

unread,

Feb 20, 2019, 11:42:40 AM2/20/19

to opencog

I think that, for starters, importing the concept-net data into the atomspace would be a good start.

This would be a multi-step process:

1) import it any-old-how

2) import it such that the format is compatible with the existing nlp subsystem

3) build some rudimentary question-answering system (on that can only answer 1 or 2 or 3 question types, from the imported data

4) see if you can do anything whizzy with PLN

I think I ordered this in terms of difficulty/complexity. I think I would be very interested in looking at, overseeing, advising steps 2,3...

--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 opencog+u...@googlegroups.com.
To post to this group, send email to ope...@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/6d4023ae-f227-4be4-b123-5482e0b154bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

cassette tapes - analog TV - film cameras - you

Ben Goertzel

unread,

Feb 20, 2019, 11:45:22 AM2/20/19

to opencog, Amen Belayneh

We already have code that imports ConceptNet into Atomspace.

Amen has worked with it...

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA36%2BHSM3HOW_rU7yK_5hKw6i%3Dq%3DYYfQ8i0ogkqV%3DHUxU-Q%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--

Ben Goertzel, PhD
http://goertzel.org

"Listen: This world is the lunatic's sphere, / Don't always agree
it's real. / Even with my feet upon it / And the postman knowing my
door / My address is somewhere else." -- Hafiz

amebel@hr

unread,

Feb 20, 2019, 10:59:43 PM2/20/19

to opencog

Hi Johannes,

The script is found at https://github.com/opencog/external-tools/tree/master/cnet_importer

Johannes Castner

unread,

Feb 21, 2019, 7:14:26 AM2/21/19

to opencog

Thank you!

johannes

Johannes Castner

unread,

Feb 21, 2019, 8:13:26 AM2/21/19

to opencog

Well, so I'd like to be able to merge JSON-LD ontologies with obo ontologies and owl ontologies, just the way that pronto does for owl and obo (here's my branch of pronto where I've already began building some JSON tools: https://github.com/jac2130/pronto). Ultimately, I think that loading in, merging and converting between ontology formats might be a common enough activity and one that getting right is worth the effort, so that it is worth the effort in having one tool that can load and convert any ontology and then also one code that loads ontological information in the most correct way possible into the AtomSpace. It makes no sense to me why there is one tool to load some genome ontology and another one to load in ConceptNet--there should be one tool for loading various formats into the AtomSpace and also that converts output from the opencog system back to those common formats (in particular, JSON-LD), so that it can be used in the usual way by other applications. The other thing that seems sub-optimal with this code is that it loads the CSV version rather than engaging with the JSON-LD data directly. Doing the latter would allow effortlessly merging other JSON-LD data with ConceptNet and adding all of that into the AtomSpace in a consistent way that can be improved and interrogated in a clean way such that it applies to all ontologies in a uniform way. I'll be working on such code, lest you think it is a waste of time?

johannes

On Thursday, February 21, 2019 at 3:59:43 AM UTC, amebel@hr wrote:

Linas Vepstas

unread,

Feb 21, 2019, 12:38:04 PM2/21/19

to opencog

Johannes,

Data formats never exist outside of what you want to do with it. Consider a question-answering system hooked to ConceptNet. You ask, "what is an instrument?" and it says "thermometer, violin". Two things have to happen here: first you have to analyze the English-language sentence to figure out what the question actually is, and then you have to convert the question into query that matches the format of your data. If your data is a table, then the query is very different than if your data is a tree ... and different if its a directed acyclic graph (DAG) .. or a non-directed graph, with cycles, with or without labels, ... whatever. Each one requires a different query.

I can ask ConceptNet "what is an instrument?" because ConceptNet knows about "words" and "concepts". But that question makes no sense for a genome database.

The above is just for question-answering. If you want to do something else: reasoning, or statistics gathering, then .. all-change. Sometimes tables are better, sometimes DAG's are better. Formats matter, they have to fit with what you're doing. There's no one ring to rule them all.

--linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/015836d5-524d-4905-b837-a48755afaa5f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Johannes Castner

unread,

Feb 22, 2019, 10:55:53 AM2/22/19

to opencog

Hi Linas,

I have a two questions:

1) I have an issue with persistence. I'm essentially mixing usage of Scheme and python. This is important because there are some nice tools in python to prepare import of knowledge into the AtomSpace and I'm trying to extend them a bit. So in python I use:

from opencog.utilities import initialize_opencog
from opencog.scheme_wrapper import scheme_eval

from opencog.type_constructors import *

atomspace = AtomSpace()

initialize_opencog(atomspace)

----------------------------------------------

but then that atomspace isn't persistent. For persistence, I have this in Scheme:

(sql-open "postgres://opencog_tester:cheese@localhost/opencog_test")
(sql-store)
(define x (ConceptNode "asdfasdf" (stv 0.123 0.789)))
(store-atom x)
(sql-close)

How do I mix these two ways of doing things, if that's possible at all?

2) So ontologies all seem to me to have the same exact structure; they are labeled graphs where some edges are directed and others are not. For my experiments, I tend to want to put ontologies into the AtomSpace--so shouldn't there just be one set of tools to use on ontologies, rather than having one script to import one ontology and then another to import another one. Take for example the ENVO ontology; it comes in owl or obo format. Then take ConceptNet and it comes in JSON-LD. But since the structure is the same for all ontologies, I feel that it would help to have one tool that translates between these formats so that they can be merged and treated the same?

I hope that you're well and I want to express my gratitude for your help!

johannes

On Thursday, February 21, 2019 at 5:38:04 PM UTC, linas wrote:

Johannes,

Data formats never exist outside of what you want to do with it. Consider a question-answering system hooked to ConceptNet. You ask, "what is an instrument?" and it says "thermometer, violin". Two things have to happen here: first you have to analyze the English-language sentence to figure out what the question actually is, and then you have to convert the question into query that matches the format of your data. If your data is a table, then the query is very different than if your data is a tree ... and different if its a directed acyclic graph (DAG) .. or a non-directed graph, with cycles, with or without labels, ... whatever. Each one requires a different query.

I can ask ConceptNet "what is an instrument?" because ConceptNet knows about "words" and "concepts". But that question makes no sense for a genome database.

The above is just for question-answering. If you want to do somethin1g else: reasoning, or statistics gathering, then .. all-change. Sometimes tables are better, sometimes DAG's are better. Formats matter, they have to fit with what you're doing. There's no one ring to rule them all.

--linas

Linas Vepstas

unread,

Feb 22, 2019, 11:40:30 AM2/22/19

to opencog

On Fri, Feb 22, 2019 at 9:55 AM Johannes Castner <jac...@gmail.com> wrote:

Hi Linas,

I have a two questions:

1) I have an issue with persistence. I'm essentially mixing usage of Scheme and python. This is important because there are some nice tools in python to prepare import of knowledge into the AtomSpace and I'm trying to extend them a bit. So in python I use:

from opencog.utilities import initialize_opencog
from opencog.scheme_wrapper import scheme_eval
from opencog.type_constructors import *

atomspace = AtomSpace()

initialize_opencog(atomspace)

----------------------------------------------

but then that atomspace isn't persistent. For persistence, I have this in Scheme:

(sql-open "postgres://opencog_tester:cheese@localhost/opencog_test")
(sql-store)
(define x (ConceptNode "asdfasdf" (stv 0.123 0.789)))
(store-atom x)
(sql-close)

How do I mix these two ways of doing things, if that's possible at all?

Scheme and python already share the same atomspace. However, when you did the following in python:

atomspace = AtomSpace()
initialize_opencog(atomspace)

you created a new, different atomspace that is not shared. These two steps are not needed. There are also other ways of working with multiple atomspaces and passing them between scheme and python, but simply skipping the above is just the simplest.

2) So ontologies all seem to me to have the same exact structure; they are labeled graphs where some edges are directed and others are not. For my experiments, I tend to want to put ontologies into the AtomSpace--so shouldn't there just be one set of tools to use on ontologies, rather than having one script to import one ontology and then another to import another one. Take for example the ENVO ontology; it comes in owl or obo format. Then take ConceptNet and it comes in JSON-LD. But since the structure is the same for all ontologies, I feel that it would help to have one tool that translates between these formats so that they can be merged and treated the same?

I cannot advise on issues like that. I'm much too far away from that to really care. As a developer, you have to make a decision: what's simplest, fastest, best, important, not important? Should I build something small simple, lightweight, temporary, or something solid, full-featured well-built that will be used for generations? I can't really guess for the above case.

-- linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/7a268f2d-38d5-4e24-8f7c-aded497845a9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Johannes Castner

unread,

Feb 22, 2019, 12:05:53 PM2/22/19

to opencog

Hi Linas,

Scheme and python already share the same atomspace. However, when you did the following in python:

atomspace = AtomSpace()
initialize_opencog(atomspace)

you created a new, different atomspace that is not shared. These two steps are not needed. There are also other ways of working with multiple atomspaces and passing them between scheme and python, but simply skipping the above is just the simplest.

But scheme_eval needs an atomspace in the first position: scheme_eval(atomspace, schemecode_string)

What do I put into the first argument of this function if not a brand new Atomspace?

Johannes

Linas Vepstas

unread,

Feb 22, 2019, 12:54:03 PM2/22/19

to opencog

On Fri, Feb 22, 2019 at 11:05 AM Johannes Castner <jac...@gmail.com> wrote:

Hi Linas,

Scheme and python already share the same atomspace. However, when you did the following in python:

atomspace = AtomSpace()
initialize_opencog(atomspace)

you created a new, different atomspace that is not shared. These two steps are not needed. There are also other ways of working with multiple atomspaces and passing them between scheme and python, but simply skipping the above is just the simplest.

But scheme_eval needs an atomspace in the first position: scheme_eval(atomspace, schemecode_string)

What do I put into the first argument of this function if not a brand new Atomspace?

from opencog.type_constructors import atomspace

The variable atomspace has already been initialized to be the atomspace that scheme is using. -- Its a global variable. When you say `atomspace = AtomSpace()` you are clobbering the previous value of this global variable.

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/792f91f6-6786-4b9a-b8ea-54ec382f398f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Johannes Castner

unread,

Feb 23, 2019, 2:57:43 PM2/23/19

to ope...@googlegroups.com

Great; thank you, that solves it brilliantly!

Johannes

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34iBg96pYorQb%2BWfeDiyq%2BFw%2BozCOn_g0XL5kkTvvyVHQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Johannes

--------------------------------------------------------------------------------------------------------
"Peace cannot be kept by force; it can only be achieved by understanding."

- Albert Einstein

Jack Park

unread,

May 29, 2019, 11:09:49 PM5/29/19

to opencog

The link at that page refers to a dead URL for the csv files.

While I did not open it to prove it, there is a csv.gz file for ConceptNet 5.6 here

https://github.com/commonsense/conceptnet5/wiki/Downloads

Reply all

Reply to author

Forward