Emacs org-mode is very powerful tool for personal knowledge management, but can be hard to learn, makes it hard to have the same content (notes) referenced in more than one place, and can be awkward for the hands.
Finding other tools inadequate for various reasons, I wrote OneModel to meet my own needs, and made it available. If you touch-type, it is extremely fast for to-do lists and notes of all kinds, and I generate the project web site from part of its data. It is much easier to learn and faster to navigate than emacs, and you can have the same content in as many places as desired, without duplication.
But it wants to be more: It uses an internal structure that has big future ideas for knowledge management, like embedding code within groups of entities, or linking across OneModel instances, so you can choose to share data from your personal organizer, or subscribe to (or copy) data from other instances: like a wikipedia but where the internal knowledge is structured so can be used for computation, rich queries etc. Imagine asking a system: what villages in history had economic improvements in a 4-year period, all external conditions being equal, and what do those cases all have in common?--that is the long-term vision of the system. The vision and internal structure are intended as be a prototype of a platform to manage all mankind's knowledge as a usefully computable whole.
The web site has a few screen shots (remember it's an ugly prototype but works well! -- I have my calendar/life notes/todos/contacts etc in it now) and a demo system to play with without installing anything.
(It is written in scala, using a simple/approachable coding style that should be readable by most programmers with just minutes of scala knowledge--I hope--and uses postgresql for the data.)
I frankly don't mind if someone else takes the ideas and does a better job with them: we can do better than managing mankind's knowledge in the form of huge sophisticated piles of words: words are not the real knowledge but a superstrate over it, and they are hard to compute well. Feedback welcome.
Here is another attempt:
1) Theory: We have many systems (wikis, evernote, cyc, etc), but all are crippled by relying on human language as a fundamental layer. To more powerfully manage knowledge, we can approach it more like an object model created on the fly by just using the system: what you know about a pen, say, is best expressed as numbers, relationships, and code (mass, owner, behavior ...); the human language words can change when the knowledge doesn't.2) Vision: Be effective on an individual level, then link OneModel instances (find others' data, subscribe to changes, copy, link, etc), to build large and comprehensive systems in wiki-like ways (with the power of the network effect), but without the crippling human-language limitations. Think wikipedia but all the data is effectively computable, and locally controllable.
3) Today: The AGPL prototype is like emacs org-mode in being keyboard- and desktop-oriented, and feeling like nested lists galore, but uses postgresql, allows having the same data linked into multiple places, is much easier to learn & use than emacs, and has a bigger long-term vision. It's (for me) the best personal organizer ever: very fast to navigate, and very flexible. The web site is generated from its data.
4) Next steps: Community-building and funding. I could really use feedback. The current target audience might be note-takers who touch type, like speed (and don't need mobile--cough), and need to be able to put the same information in more than one place in their notes. And anyone who wants to help move the big picture forward. Like, I hope to add anki-like features, and ways to attach code to classes of objects that were "modeled" on the fly as a side-effect of using the system (eg, so you can change the date on to-dos, in ways you specify, with simple code, or eventually run simulations, etc).
A number of the things you state as objectives seem to run afoul of the full employment theorem [wikipedia.org]. Your software may in fact be useful, but some of your aspirational goals seem to be frustrated by the problem that it's impossible to determine what the optimal granularity for data is. In your villages example, picking equivalence classes for your "all external conditions being equal" modifier is fraught with peril. Even if we suppose that there is some real, eternal law to be divined by this analysis, it's not going to be identified by every choice of equivalence classes. The set of reasonable equivalence classes is going to be quite large and there will be a variety of choices which do not find any significant explanatory variable and others which effectively cherry pick a spuriously significant explanatory variable. Before you can hope to look at similarities in economic progress of villages, you first need a theory of what makes two villages similar.
Stated another way, there are results in algorithmic information theory which say that there is no a priori way to choose an optimal granularity for atoms of knowledge. This is the basis for the intractability of some big picture problems in formal logic, computer programming, statistical inference, machine learning, and human learning. The issues in that last item are noted in Plato's Socratic dialogues, with the Socratic position that knowledge is unperfectable being contrasted with a Sophistic position that perfect knowledge of virtue was possible and teachable.
Thanks for your perceptive comment. Maybe as the system matures and is more used, we will model things at different granularity levels at different times, or find the best ways to meet the goals we can meet. I don't expect to run into that as a core blocker for some time. Participation welcome :)
https://pairlist10.pair.net/mailman/listinfo/om-announce [pair.net]https://pairlist6.pair.net/mailman/listinfo/om-list [pair.net]
This is a visionary presentation. Not likely to interest technical people by itself -- it's easy to be visionary without usable results. The presentation you made about entities and attributes, with attributes specified, was technical, and straightforward. It fails to express the purpose of the system and comes across as yet another data structure.
You need both of these; either on its own falls flat.
Thanks for these comments. Maybe between them and what is happening on the mailing list it will be improved.