I am interested to contributing to Opencog. What do I need to learn, and how soon can I be an active contributor ?--
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+unsubscribe@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/c87d0f11-8750-4f9f-be5f-f28fa640328b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I am interested to contributing to Opencog. What do I need to learn, and how soon can I be an active contributor ?
You bring up a good point. It is quite difficult to maintain. Not only is it a very complex system design, but the implementation is also quite complex, containing a lot of legacy code, unfinished features, experiments, and whatever else. I used to thumb my nose at the fact that not enough attention seems to be focused on simplifying the implementation. But now I have a lot of respect for the project's ability to thrive for so long despite the barriers to entry.
Keep in mind though that at many software companies, it can take a number of months of full time effort before a professional engineer becomes productive, even despite efforts to reduce this time!
And this is also a research project, with the core contributors being focused on research. I don't think they would be able to focus on maintainability.
My approach to solving it, if I were to decide now, would be to first get a lot of feedback on what new and existing contributors find difficult about the project's implementation, maintainability, and ramp up time. Would also look at past posts meticulously, to find patterns.
Some recommendations that might be made (subject to approval and further analysis): Would consider gradually moving parts of the C++ into idiomatic C# (fully open source now), or even F# if functional programming environment is desired. Any C++ developer can understand C#, and almost anything you can do in C++ can be done in C#, but with less complex code and easier troubleshooting. Even if half the core developers were to prefer python (for example) I'd try to persuade everyone that C# is a better choice due to the fact that it probably has the lowest learning curve of all major languages, is syntactically and idiomatically similar to C++, and has high compatibility due to the VM runtime.
Would clean up the build scripts or even rewrite them completely (the scripts aren't bad, but they're old and probably need an overhaul). Toss out all support for alternate OS, alternate compiler, etc. At least until support can be re-added under a newer build system. There is (or was) a lot of "junk DNA" code in the build script that only hinders efforts to understand it or improve it. Ever hear of the "broken window problem"? CMake has a high learning curve (and is it really necessary when using one OS?) so I'd probably do away with it.
My vote is worth about zero though because I don't have the physical stamina or mental willpower to work on this in addition to my day job (it would not be easy work, and likely some of the hardest coding work I've ever done, which is saying something).
--
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+unsubscribe@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/CAL7_Mo-y6hgsjDPjbuJBtqcTeCiMTty9PHbHmNdGQ1dMstJWCA%40mail.gmail.com.
By the way, I lurked for 10 years before making my first real contribution. Don't blame the project for that one!
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAMyYmr9AXLz0o_MOOXP_Vab3ece7RKN0vhQ4QNfdKEe1Ehjzog%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35-o4fXnMEZK%2BvUq%2BDwaMupeG-3pra-Xie4njc%2BtpdnXQ%40mail.gmail.com.
--
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+unsubscribe@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/CAMyYmr--p%2BDpT7ZHOwFQ9CnsTE8Xri9s3gucO1Qb8t0b3EY8WA%40mail.gmail.com.
--
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+unsubscribe@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/CAMyYmr-gn6OdTnSgGa5SZyOxtkTXJL%3DXY9d-2tv4SD%2B4ibVq%2BQ%40mail.gmail.com.
On Oct 1, 2017 3:47 PM, "Anastasios Tsiolakidis" <helle...@gmail.com> wrote:
>
> Well isn't OpenCog having a busy weekend :) As a lurker I have already expressed my dissatisfaction at "advanced C++" which is the trend in the project, and would probably carry over my disapproval of "idiomatic C#". There is absolutely no reason for the coding to be more difficult to comprehend that OpenCog's design itself. If anything, the code should make plain and simple what the bloody design is trying to do!
But it's not a matter of what the actual code looks like! The tooling, the compilation times, libraries, and so on, all require a higher level of expertise on the C++ side. Even though Linus knows that understanding it is not needed, the fact is that based on the above fact, C++ is by and large a language for experts and to a lesser extent academics. So if you want non-academic, non-experts (which is the vast majority of the FOSS community) then I recommend polishing the build scripts as needed, fixing all reported issues with the build (if someone has to POST here because of a build problem, then it's likely a defect). Then make sure the newbie tutorials exist, are easy to find, updated, and that they steer people far the hell away from the C++ code :)
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UyGXczixVQoZqn6KSBKCd9CnYLtuUNqMh6uY5MHhPfaA%40mail.gmail.com.
Hi,
On Sun, Oct 1, 2017 at 9:30 AM, Linas Vepstas <linasv...@gmail.com> wrote:
> I mean, how do I tell people "this code compiles but probably doesn't work
> and no one uses it" vs. "this code is the bedrock foundation that we
> jelously protect from damage"
The way I see it handled most often is to only allow
production-quality, working code in the master branch.
But didn't the
project try to enforce that with CircleCI (I think) and you had an
issue with that?
>
It might just be my anti-C++ bias talking.
Well isn't OpenCog having a busy weekend :) As a lurker I have already expressed my dissatisfaction at "advanced C++" which is the trend in the project, and would probably carry over my disapproval of "idiomatic C#". There is absolutely no reason for the coding to be more difficult to comprehend that OpenCog's design itself. If anything, the code should make plain and simple what the bloody design is trying to do! Now, my particular wet dream would be to see people pulling together their own "free resources", like the free tiers at AWS, Google Cloud etc, to create a hive-mind. If somebody was brilliant enough to throw away big chunks of the code and instead achieve (some of) the same results with a DB of sorts, AWS lambda etc, that would be quite something. Then, for the parts that don't fit the "cloud" box, if someone could come up with the "CloudCog", some probabilistic graph, inference engine or whatever is missing from the garden variety PAAS and SAAS, then we could really be heading somewhere. I don't know much about the project beyond the demos, but I do believe the project is being hurt by the general unavailability of a constantly running instance that "does something", whatever that maybe, and somehow can be accessed by the public, eg through an API. Presumably this new hedge fund thing may be the closest OpenCog has come to being a 24/7 system, and Ben will probably tells us if he finds out a better way to do things with and without this codebase
AT
--
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+unsubscribe@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/2668e4aa-5324-4a66-9786-c795daad157c%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35uH4eecM_zh%3DvnNXwMtTUwEkv9qSXOGBCQjgw1kd0How%40mail.gmail.com.
Ivan,
This is essentially the vision I have for the project too. I wish I could say that it could be done by a determined volunteer, but the logistics are very difficult for pulling this off. It would require multiple experienced and skilled engineers working full-time, possibly paid. That isn't going to happen by itself.
Maybe there is a realistic path to making it happen. Let's talk in more detail later since I'm interested too, but I can't promise any commitment as its tough these days for me to put in the hours in addition to what keeps my bills paid...
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6X_KLTw1t1HaX1YK4TDPuvGNScUaN%3DVE0ncvKcQNJZufw%40mail.gmail.com.
>>>> an email to opencog+unsubscribe@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/2668e4aa-5324-4a66-9786-c795daad157c%40googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> --
>>> "The problem is not that artificial intelligence will get too smart and
>>> take over the world," computer scientist Pedro Domingos writes, "the problem
>>> is that it's too stupid and already has."
>>>
>>> --
>>> 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+unsubscribe@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/CAHrUA35uH4eecM_zh%3DvnNXwMtTUwEkv9qSXOGBCQjgw1kd0How%40mail.gmail.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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+unsubscribe@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/CAB5%3Dj6X_KLTw1t1HaX1YK4TDPuvGNScUaN%3DVE0ncvKcQNJZufw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscribe@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/CAMyYmr8fZTmm7Z%3D_kqLWsX3W5NcTE-Dvb6U4zEmDmp%2BSmLzPpw%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Ben Goertzel, PhD
http://goertzel.org
"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin
--
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+unsubscribe@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/CACYTDBc9EySL0oMPmm0Xq7z4HoYW0uVY8EUm9jzQ0Qf7gJjqsQ%40mail.gmail.com.
>>>> an email to opencog+unsubscribe@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/2668e4aa-5324-4a66-9786-c795daad157c%40googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> --
>>> "The problem is not that artificial intelligence will get too smart and
>>> take over the world," computer scientist Pedro Domingos writes, "the problem
>>> is that it's too stupid and already has."
>>>
>>> --
>>> 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+unsubscribe@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/CAHrUA35uH4eecM_zh%3DvnNXwMtTUwEkv9qSXOGBCQjgw1kd0How%40mail.gmail.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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+unsubscribe@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/CAB5%3Dj6X_KLTw1t1HaX1YK4TDPuvGNScUaN%3DVE0ncvKcQNJZufw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscribe@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/CAMyYmr8fZTmm7Z%3D_kqLWsX3W5NcTE-Dvb6U4zEmDmp%2BSmLzPpw%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Ben Goertzel, PhD
http://goertzel.org
"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin
--
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+unsubscribe@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/CACYTDBc9EySL0oMPmm0Xq7z4HoYW0uVY8EUm9jzQ0Qf7gJjqsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
I am here since the fall of last year (around year) and if I am allowed, I would like to make the following thoughts that may make OpenCog project more attractable in the eyes of developers and users:1) The first feature of OpenCog is its internal complexity. One can read two-volume AGI book and wonder about ideas about organizing mind agents and processing nodes in multiprocessor, distributed architectures, about load balancing and execution priorities, internode communication, etc. All these are pretty low level technicalities that require the expertise of system programmers, but this is quite rare expertise.
I have this discussion in other thread https://groups.google.com/forum/#!topic/opencog/X_eKhNErmC8 about possibility to use external software and external services more extensively in OpenCog project. So far OpenCog project is about graph database, about graph pattern matching and graph pattern mining, about rule engine - but all these technical services are separate project today. I guess that in the time of making first OpenCog lines, there were no graph databases, the resarch and tools of graph mathcing and mining was only ascent field. But today the situation is far more different - today graph databases and mathcing/mining projects are available. Maybe the development strategy should be changed - maybe one should more extensively use these projects and there is mismatch of requirements then contribute to these speciality projects back and not to try overdo them.
E.g. I do not believe that it is economically feasibile to reimplement graph database. There are graph database projects, there is ThinkerPop (JDBC) like interface and there is Gremlin (SQL) like language.
And can implement algorithms in the graph database-agnostic way and use all the industrial power of the best database available. Scientists do use commercial off-the-shelf computers for HPC, why not to use industrial software? And similar things we can say about use of external reasoners (linear logic, Coq, Isabelle, etc.).
I guess, that OpenCog graph database, matcher and miner features are more or less completed, so this work is not required for novice who would like to contribute to AGI with OpenCog.
But the question still stands. If one starts to think about load balancing, about scalability - can we safely assume that from the technical point of view OpenCog surpasses the industrial graph databases?
And what to do if our Atomspaces are growing and growing and there is need to improve this in the project?
Should be move to the low level job of systems programmers which requires so different expertise?
I am just afraid whether the project is going in the right direction. People would like to concentrate on their models and knowledge bases not on the techniques.
2) Second obstacle to my adoption of OpenCog was some missed documentation. E.g. other programming systems have BNF formalization of their languages and the strict and exhaustive list of the constructions and available patterns. OpenCog has very good list of all the node and link types but sometimes I would like to have strict definitions what nodes can be used with what links. At present I am a bit afraid that I have to do some experimentation.
3) Third and last obstacle to my adoption was remoteness of the OpenCog ideas and concepts.
It was great to have OpenCog experience because it invites me to look deeper in the OO notions.
I.e. OpenCog is thinking in more basic terms of extensional in intensional inheritance/association, OO/UML modelling oversimplifies things. It is good, but still - some canonical mapping from OpenCog notions to the more widely adopted knowledge modelling notions would be helpful.
Even more so because I am pretty sure that there are people who have made such mappings for themselves.
And similar things I can say about the probabilistic term logic that is underlying OpenCog - it is not the most popular thing in the market.
Again, I am not against such approach, I just invite to present some canonical mapping to the more popular logics. I don't exactly remember but AGI books had such explanation, if I am correct.So - the general conclusion is: there are ideas about modularization of OpenCog. But it seems to me that everyone here expects that modules will be developed by OpenCog society. My view is different. Modularization is required but we should use already available software (be it external open source) for graph database, mathcer, miner, rule engine and grow these projects and grow ourselves with the growth of these external projects. That is the true modularization.Well, please, don't take seriously my thoughts I just expressed my opinions. I am in quite difficult position. I need to make decision to what knowledge base to commit and I am afraid not to take the wrong decision. There are so much factors under consideration and sure, everyone has his or her opinions about the ideal project. But things are coming and going. I am working in my profession on broadcasting system and I have seen how much the TV adverstising business is changing and how its supporting software is changing too. So - why should be expect that the software for cognitive architectures remains static.There were talks about funding. But funding for what? For developing yet another graph database? Facebook, Google exploited open source software as much it was possible during the initial growth phase and it was the base on which the success story was built. Of course, after some time they started to contribute back to the community. And they are still engaged and open with the community and it is the mutual growth and for mutual benefit.
--
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+unsubscribe@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/f52988a4-7430-4d56-a67d-ec9087da83ce%40googlegroups.com.
--
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+unsubscribe@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/CAMyYmr97QJPEeEsGjG%2BQyC6xfujcPnX2L01ub4HpOxpZy8GXaA%40mail.gmail.com.
--
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+unsubscribe@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/a261e2b5-7d6e-74f9-fe87-cd83304adb2a%40gmail.com.
> To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@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/CAMyYmr-T4gevcMh_2mYHko-YwuRcCK6dyBfGZVwYT%2BuizjH6PQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Ben Goertzel, PhD
http://goertzel.org
"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin
--
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+unsubscribe@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/CACYTDBfVnqsuiJV5MbFu4_1rkKffZESjaVroUmkEUDc1K0cUNw%40mail.gmail.com.
On 10/06/2017 02:10 AM, Linas Vepstas wrote:
it would be nice to have a fast crisp prover so that the system could jump to conclusions, and pln more slowly in the background.
Yes, even for our rule engine alone there is a benefit to that. On top of being faster to evaluate, crisp rules tend to have less premises than their probabilistic counterparts.
Then the question is how to set the TV of these conclusions. If the axioms are crisps with (stv 1 1) or (stv 0 1), then the conclusions would be (stv 1 1) or (stv 0 1). But if the axioms are non-crisp, then I guess the crisp rules could set (stv 1 Epsilon) or (stv 0 Epsilon), just to express that something is possibly true or false. Or else we can create a new TV type for it.
Nil
> To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@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/CAMyYmr8UnF1vr7BwF%2BY53xdyihdLbCEL72mJ9DdkOVAFng4Zdw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Ben Goertzel, PhD
http://goertzel.org
"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin
--
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+unsubscribe@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/CACYTDBcuRat55n4E3FjKLWtZx-6fWHwiXA7n-XTrQhVDrRSzqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Certainly an idea to keep in mind.
Nil
I find this idea exciting! It seems plausible, doable ...
--linas
Nil
3) We should be thinking of semantic flows instead of the atoms of state that result from changes in flows. Semantic flows represent isomorphisms of state applied to a sub-graph.
This happens to be the starting point for SingulairyNET agents. What flows in as data and what flows out as results? So we are working on this problem at the high-level while I and others are thinking about how best to represent the abstract constructs definable in atomese.
In many ways, I see these times for AGI as akin to the early days of programming when we first made the jump from machine language to assembly language and then we got C and Fortran and Cobol, with the semantics tied much more closely and directly to the problem domain: whether systems- or scientific- or business-programming.So I see OpenCog Atomese as the assembly code for Sophia's mind. We want it to stay flexible because we do not want to limit what is possible. But it is too much work to write in assembly all the time. we need compressions of complexity and a higher-level form for more efficient and expressive work at higher levels.We have not yet built, anyone anywhere yet, the semantic analog to C for AI, let alone the more modern variants like Go, Rust, Swift or even Python.
There is an impedance mismatch between the ways that current batch-oriented Von-Neumann bottlenecked systems run and the ideal ways that a mind wants to learn in parallel. There is a greater need for efficient shared semantic context among the many parts communicating. There is a greater need for visualization into the implications and nuanced semantics implied by the connections.Much work to be done but all identified and doable.
For the last ten years, I've been thinking of the atomspace as a "graph database". In the last 6+ months, I'm starting to realize that this is the wrong viewpoint. I think I know a better one, but it takes some explaining.
Certainly an idea to keep in mind.
Nil
I find this idea exciting! It seems plausible, doable ...
--linas
Nil
... a simple and convenient mechanism for working with graphs "locally", by making the nearest-neighbors of a vertex apparent.
The traditional textbook-canonical way of specifying a graph is to state that it is a set of vertexes, and a set of edges that connect pairs of vertexes. The problem with this description is that given any vertex, one has no idea of what edges are connected to it, without scanning the entire set of edges. Another problem is that vertexes and edges are not composable; that is, when they are composed together, they are no longer vertexes or edges, but a more general type: a "subgraph". By contrast, sheaves carry local information, and are composable.
Given a vertex V, a "section" is defined as a set of pairs (V,E) of that vertex V and all edges E that are attached to it. That's it! Very simple! A section can be envisioned as a "spider", with the vertex V as the body of the spider, and the edges as the legs of the spider.
Sections are composable, in that several can be connected together by joining ("connecting") edges. The result is still a section, in that it has a central blob as the spider-body, and a whole bunch of legs sticking out. Composing sections in such a way that the edges connect only in legal ways is called "parsing".
Another way of visualizing sections is to envision a jigsaw-puzzle piece instead of a spider. The vertex V is a label on the puzzle-piece, and each leg is a tab or slot on the puzzle-piece. The tabs or slots are now obviously connectors: this emphasizes that jigsaw-puzzle pieces can be connected together legally only when the connectors fit together. Again: the act of fitting together puzzle-pieces in a legal fashion is termed "parsing".
In standard mathematical terminology, the spider-body or jigsaw-label is called the "germ". It is meant to evoke the idea of a germinating seed, as will become clear below.
Diagramatic illustrations of jig-saw puzzle-pieces can be found here: