Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cyc: History's Forgotten AI Project

outsiderart.substack.com

Post reply on HN
Print view View original

11–20 of 145 posts

Re: Cyc: History's Forgotten AI Project

#11

Post by gumby »

This is a pretty good article.

I was one of the first hires on the Cyc project when it started at MCC and was at first responsible for the decision to abandon the Interlisp-D implementation and replace it with one I wrote on Symbolics machines.

Yes, back then one person could write the code base, which has long since grown and been ported off those machines. The KB is what matters anyway. I built it so different people could work on the kb simultaneously, which was unusual in those days, even though cloud computing was ubiquitous at PARC (where Doug had been working, and I had too).

Neurosymbolic approaches are pretty important and there’s good work going on in that area. I was back in that field myself until I got dragged away to work on the climate. But I’m not sure that manually curated KBs will make much of a difference beyond bootstrapping.

Re: Cyc: History's Forgotten AI Project

#12

Post by zozbot234 »

observationist wrote: post #7
mepian wrote: post #3

I wonder what is the closest thing to Cyc we have in the open source realm right now. I know that we have some pretty large knowledge bases, like Wikidata, but what about expert system shells or inference engines?

OWL and SPARQL inference engines that use RDF and DSMs - there are LISPy variants like datadog still kicking around, but there are some great, high performance reasoner FOSS projects, like StarDog or Neo4j https://github.com/orgs/stardog-union/ Looks like Knowledge Graph and semantic reasoner are the search terms du'jour, I haven't tracked these things since OpenCyc stopped being active. Humans may not be able to eff…

You can actually do "inference" or "deduction" over large amounts of data using any old-fashioned RDBMS, and get broadly equal or better performance than the newfangled "graph" based systems. Graph databases may be a clear win for very specialized network analysis, but that is rare in practice.

Re: Cyc: History's Forgotten AI Project

#13

Post by p_l »

zozbot234 wrote: post #12
observationist wrote: post #7

Earlier quoted context omitted.

OWL and SPARQL inference engines that use RDF and DSMs - there are LISPy variants like datadog still kicking around, but there are some great, high performance reasoner FOSS projects, like StarDog or Neo4j https://github.com/orgs/stardog-union/ Looks like Knowledge Graph and semantic reasoner are the search terms du'jour, I haven't tracked these things since OpenCyc stopped being active. Humans may not be able to eff…

You can actually do "inference" or "deduction" over large amounts of data using any old-fashioned RDBMS, and get broadly equal or better performance than the newfangled "graph" based systems. Graph databases may be a clear win for very specialized network analysis, but that is rare in practice.

Graph databases win in flexibility and ease of writing the queries over graphs, honestly.

Of course the underlying storage can be (and often is) a bunch of specially prepared relational tables.

But the strength in graph databases comes from restating the problem in different way, with query languages targeting the specific problem space.

Similarly there are tasks where SQL will be plainly better.

Re: Cyc: History's Forgotten AI Project

#14

Post by Rochus »

gumby wrote: post #9
mepian wrote: post #3

I wonder what is the closest thing to Cyc we have in the open source realm right now. I know that we have some pretty large knowledge bases, like Wikidata, but what about expert system shells or inference engines?

Err…OpenCyc?

Unfortunately no longer (officially) available; and only a small subset anyway.

Re: Cyc: History's Forgotten AI Project

#15

Post by zozbot234 »

p_l wrote: post #13
zozbot234 wrote: post #12

Earlier quoted context omitted.

You can actually do "inference" or "deduction" over large amounts of data using any old-fashioned RDBMS, and get broadly equal or better performance than the newfangled "graph" based systems. Graph databases may be a clear win for very specialized network analysis, but that is rare in practice.

Graph databases win in flexibility and ease of writing the queries over graphs, honestly. Of course the underlying storage can be (and often is) a bunch of specially prepared relational tables. But the strength in graph databases comes from restating the problem in different way, with query languages targeting the specific problem space. Similarly there are tasks where SQL will be plainly better.

> ease of writing the queries over graphs, honestly

The SQL standard now includes syntactic sugar for 'Property Graph Query'. Implementations are still in the works AIUI, but can be expected in the reasonably near future.

Re: Cyc: History's Forgotten AI Project

#17

Post by pfdietz »

gumby wrote: post #11

This is a pretty good article. I was one of the first hires on the Cyc project when it started at MCC and was at first responsible for the decision to abandon the Interlisp-D implementation and replace it with one I wrote on Symbolics machines. Yes, back then one person could write the code base, which has long since grown and been ported off those machines. The KB is what matters anyway. I built it so different peop…

Is Cyc still implemented in Lisp?

Re: Cyc: History's Forgotten AI Project

#18

Post by mepian »

pfdietz wrote: post #17
gumby wrote: post #11

This is a pretty good article. I was one of the first hires on the Cyc project when it started at MCC and was at first responsible for the decision to abandon the Interlisp-D implementation and replace it with one I wrote on Symbolics machines. Yes, back then one person could write the code base, which has long since grown and been ported off those machines. The KB is what matters anyway. I built it so different peop…

Is Cyc still implemented in Lisp?

Yes: https://cyc.com/archives/glossary/subl/

Also see: https://www.youtube.com/watch?v=cMMiaCtOzV0

Re: Cyc: History's Forgotten AI Project

#19

Post by p_l »

zozbot234 wrote: post #15
p_l wrote: post #13

Earlier quoted context omitted.

Graph databases win in flexibility and ease of writing the queries over graphs, honestly. Of course the underlying storage can be (and often is) a bunch of specially prepared relational tables. But the strength in graph databases comes from restating the problem in different way, with query languages targeting the specific problem space. Similarly there are tasks where SQL will be plainly better.

> ease of writing the queries over graphs, honestly The SQL standard now includes syntactic sugar for 'Property Graph Query'. Implementations are still in the works AIUI, but can be expected in the reasonably near future.

Having seen PGQL, I think I'll stay with SPARQL.

And for efficient implementation the database underneath still needs to have extended graph support (in fact, I find it hilarious that Oracle seems to be spearheading it, as they have previously canceled their graph support around 2012 - enough that I wrote about how it was deprecated and removed from support in my thesis in 2014.

Re: Cyc: History's Forgotten AI Project

#20

Post by totetsu »

p_l wrote: post #13
zozbot234 wrote: post #12

Earlier quoted context omitted.

You can actually do "inference" or "deduction" over large amounts of data using any old-fashioned RDBMS, and get broadly equal or better performance than the newfangled "graph" based systems. Graph databases may be a clear win for very specialized network analysis, but that is rare in practice.

Graph databases win in flexibility and ease of writing the queries over graphs, honestly. Of course the underlying storage can be (and often is) a bunch of specially prepared relational tables. But the strength in graph databases comes from restating the problem in different way, with query languages targeting the specific problem space. Similarly there are tasks where SQL will be plainly better.

Every time I try to write a query for GitHub’s graphql API I lose a few hours and go back to rest. May be it’s easy if all the edges and inputs are actually implemented in ways you would expect.
Post reply on HN