jack, there is lots of work is being done applying opencog to biomedical problems and we've opened up development of the annotation-scheme code and all associated database imports to the atomspace (bio-atomspace) as part the covidathon hackathon. here are links to descriptions of what is available if you are interested in checking it out, formal participation in the hackathon isn't necessary:
details on data import to the bioatomspace https://docs.google.com/document/d/16zfY7OZtHO66mfujLdZ0-3VALXUTvxeeo4dW2ASBiNs/edit?usp=sharing <https://slack-redir.net/link?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F16zfY7OZtHO66mfujLdZ0-3VALXUTvxeeo4dW2ASBiNs%2Fedit%3Fusp%3Dsharing&v=3>2 files some more detailed thoughts on bio-data visualization are at https://docs.google.com/document/d/1Z_uGGM3MwZ1r6Rc3U044tAnouVNRLzdYfodOpSn0ymw/edit <https://slack-redir.net/link?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Z_uGGM3MwZ1r6Rc3U044tAnouVNRLzdYfodOpSn0ymw%2Fedit&v=3> and some more detailed thoughts on automated hypothesis formation regarding COVID-19 therapies are at https://docs.google.com/document/d/1QAP00zGlpn2Bnrsug622DbrB8s6l3RzlfYUw14rszQw/edit <https://slack-redir.net/link?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1QAP00zGlpn2Bnrsug622DbrB8s6l3RzlfYUw14rszQw%2Fedit&v=3> On Sunday, April 26, 2020 at 4:50:10 PM UTC-4, linas wrote: > > > > On Sun, Apr 26, 2020 at 1:30 PM Jack Park <[email protected] > <javascript:>> wrote: > >> I'm trying hard not to be an advocate of anything; rather, I'm in >> exploration mode. >> >> Tell you what: I'd like to see (have not yet found) some solid examples >> of AtomSpace - full-on knowledge graph implementations, whatever. Something >> to be able to follow through one or two complete examples which are more >> than toy exercises. >> > > The latest blog entry? https://blog.opencog.org/ > > You're not going to find "complete examples" anywhere -- if you can't > master the toy examples, a "complete example" will not make anything > easier. That said -- this all is open source, so --- > > The mozi biochem annotation code -- > https://github.com/MOZI-AI/annotation-scheme > It handles datasets with some 10-50 million protein and gene encodings. > You would have to write to the developers to get sample datasets, I'm not > sure if they are proprietary or what. > > There used to be the old Hanson Robotics behavior code; it has fallen away > but it had a bunch of scripts for reacting via facial expressions, to > visual cues (people entering the room, making hand-gestures). It > implemented something called "behavior trees" (see wikipedia) -- what's > left of it is here > https://github.com/opencog/opencog/tree/master/opencog/eva but I'm not > sure where the ROS integration has moved to. It used to be here: > https://github.com/opencog/ros-behavior-scripting -- the repo is still > there, but the contents were gutted and moved somewhere else, not sure > where. Maybe some hanson robotics tree. The robot control stuff was here: > https://github.com/opencog/blender_api -- with some effort, the original > pipeline can be made to work again. > > Somewhere there's an AIML import module: you can import everything that > AIML does, and run it in a compatibility mode. The goal of doing this was > to also attach vision and motor control. That never got far, because AIML > sucked. AIML had maybe 50K or 100K stimulous-response pairs, so that was > maybe under 1M atoms, not sure. Here: > https://github.com/opencog/opencog/tree/master/opencog/nlp/aiml -- it > worked in real-time, enough to get the robot to trade shows and on TV. > > Then a switch to ChatScript, but chatscript is far more complex than AIML, > so they used something called "ghost" -- > https://github.com/opencog/opencog/tree/master/opencog/ghost -- the > chatscript also has about 20K-ish conversational interactions, gambits, > responses, so maybe 200K atoms ?? no clue, actually. Also this: > https://github.com/opencog/loving-ai-ghost and this: > https://github.com/opencog/ghost_bridge and this: > https://github.com/opencog/loving-ai > > The robot stuff and chatbots are abandoned for a variety of reasons. > Partly because chatbots suck and partly because there's no money. But also > because chatbots got little/nothing to do with the "hard problem" of AI, so > its boring to Ben, and to me, and to most anyone else working on this > stuff. Again -- that's why there's a focus on learning. > > That leaves the genomics/proteomics stuff, which is interesting because > you can actually do data mining that other bio systems cannot do. > > -- Linas > > > >> >> On Sun, Apr 26, 2020 at 11:04 AM Linas Vepstas <[email protected] >> <javascript:>> wrote: >> >>> About opencrux... below, >>> >>> On Sun, Apr 26, 2020 at 10:24 AM Jack Park <[email protected] >>> <javascript:>> wrote: >>> >>>> That's a useful observation. I wonder if it has anything to do with the >>>> fact that they give appearances more of offering a platform aimed at >>>> solving real-world problems as compared to a platform for language >>>> modeling >>>> research? >>>> >>>> Their landing page reads rather differently from that of the AtomSpace >>>> landing page. They make results-oriented promises; I don't see that on >>>> the >>>> AtomSpace landing page. >>>> >>>> Their landing page appears to be the work of skilled marketing types; >>>> the AtomSpace landing page appears to be the work of, well, not skilled >>>> marketing types. Their top nav bar says Products, Solutions, Use Cases, >>>> Community, ...; AtomSpace is a MediaWiki, one very familiar to developers, >>>> but not to business oriented people. >>>> >>>> What if AtomSpace ignored all the cool buzz words and opened with >>>> problems it can solve, ways people can start using it right out of the box >>>> without building it, tuning it, etc? >>>> >>>> Would you, as a scientist, be able to live with wall-street-oriented >>>> thinkers taking over your pet projects and packaging them up for far >>>> less-skilled consumers? >>>> >>>> I think this is an issue faced by a lot of us. >>>> >>> >>> Quite right. We've never had anyone interested in marketing participate >>> in the project. Marketing is a skill, and unlike open source, there is no >>> "open marketing", so you have to pay these people actual $$$ to get slick >>> content. >>> >>>> >>>> I studied Grakn carefully; the front story is one, for me, of some >>>> attraction to the apparent simplicity of the system; the back story, for >>>> me, is that Grakn appears optimized in ways which get in the way of >>>> allowing me to push it in ways I believe it should be pushed; a problem of >>>> ontological commitments I cannot undo, so I just walk away. >>>> >>>> For a really interesting case for comparison, take a look at >>>> https://opencrux.com/ >>>> >>> >>> Well, care to be specific? I suppose it's possible to put a >>> prolog/datalog API on top of the atomspace. I'm sufficiently removed from >>> that world that I would not want to even begin without a lot of >>> arm-twisting, but I can consult. >>> >>> I'm not sure what to say about other things. Bitemporality? We have a >>> concept of a space-time server, optimized for dealing with time .. and >>> space coordinates. It's neglected... >>> >>> Document-graph? Sure, cause why not? Seems easy to me... >>> >>> Back-ends other than postgres? That's interesting. It's not "hard" - its >>> not conceptually hard, and also the infrastructure/API is already in place. >>> But it does require some fair amount of slogging. One would have to be >>> enthusiastic about it. >>> >>> Datalog queries? I'm certain that anything you can say in datalog, you >>> can say in Atomese, and so its a matter of writing a converter/translator >>> that accepts datalog as input and spews atomese as output. How hard is >>> this? No clue. You've actually messed with this kind of stuff, you'd know >>> better. Again -- everything that is a "symbol" in prolog is an atom in >>> atomese. The atomspace is pretty much nothing more than a glorified symbol >>> table. >>> >>> ... and this seems to be the key insight that the opencrux developers >>> have made: symbol tables are (ad-hoc, in-RAM, poorly-designed) databases. >>> Rip out the ad-hoc symbol table of programming language XYZ, replace it >>> with a real, actual database, and wow ... off we go on a wild ride. I'm >>> trying to think of what programming languages XYZ this could be the most >>> interesting for... where you'd get the most bang-for-the-buck. Maybe prolog >>> -- maybe that is the lesson from opencux ? >>> >>> Care to suggest an easily-hackable version of prolog/datalog on which >>> this experiment could be done? Just for the heck of it? >>> >>> I mean, you could do this trick for python or javascript ... I don't >>> think the python community would accept it, it would be too crazy and weird >>> for them. The javascript folks might .. but they already have some pretty >>> decent infrastructure already, so they don't need something this low-level. >>> They've done this integration at a higher level, already. (programming in >>> javascipt is far more mind-expanding than python. Python shuts down your >>> world-view, narrows your thinking. Blinds you to possibilities. javascript >>> does the opposite.) >>> >>> --linas >>> >>>> >>>> On Sat, Apr 25, 2020 at 7:48 PM Linas Vepstas <[email protected] >>>> <javascript:>> wrote: >>>> >>>>> <snip> >>>>> I dislike promoting competitors, but the grakn.ai system has taken >>>>> some baby-steps in this general direction. I'm envious that they are far >>>>> more popular/funded/suported/used than the atomspace. >>>>> >>>>> --linas >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "link-grammar" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected] <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/link-grammar/CAH6s0fydKLSFN40GykJ5FNR0d_DKqPi0yrAyVU%2B4wpFd6aig9Q%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/link-grammar/CAH6s0fydKLSFN40GykJ5FNR0d_DKqPi0yrAyVU%2B4wpFd6aig9Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> cassette tapes - analog TV - film cameras - you >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "link-grammar" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/link-grammar/FMGJq5YhbME/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/link-grammar/CAHrUA36GQq2B6nrFcQxN7DqQ8gZJH1DqvvaUkBp54rcR2b89Mw%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/link-grammar/CAHrUA36GQq2B6nrFcQxN7DqQ8gZJH1DqvvaUkBp54rcR2b89Mw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "link-grammar" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/link-grammar/CAH6s0fxp6nFOVBvBLuDkW-i0nazm2FwgucGe5DHs_Enur83Gcw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/link-grammar/CAH6s0fxp6nFOVBvBLuDkW-i0nazm2FwgucGe5DHs_Enur83Gcw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > cassette tapes - analog TV - film cameras - you > -- 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/ede4b118-69d6-4f8a-9404-816355c1cdb6%40googlegroups.com.
