emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] "atomic knowledge" modeling tool


From: luke call
Subject: Re: [O] "atomic knowledge" modeling tool
Date: Mon, 1 Feb 2016 15:15:03 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 01/31/16 05:32, Eric S Fraga wrote:
> I'll bite: so what does onemodel solve that org does not do?  Serious
> question as I have gone through the web site and I cannot see the USP of
> this system.

Also a really good question. I'll state it as compared to what I remember of org-mode, but it's been years and I was not a power user. For someone who hasn't known of anything like org-mode I'd present it differently.

Short version:
1) Faster nagivation, and faster sorting/reorganizing of data, so you can do it almost without thinking about the app, just about the info. 2) A given entity (with all eventual references it contains) can be present in as many places as you want (effectively link anything anywhere as many times as desired). Go from X to Z in a single keystroke, no matter where you are, if you want.
3) Much easier to learn.
4) No artificial boundaries between data: no having to open separate files. Everything can be integrated into one.
5) Extremely large amounts of data without becoming unwieldy.
6) (Not exactly what you asked, but important) A very different future vision because the data in OM is structured to be *computable*, opening up features that are hard to do when processing semi-structured text, or human language as a primary representation. A current example of this (automatic work journal) is below in the detailed section, with other examples.


Longer version (feedback appreciated):

1)
I'm not org-mode power-user but what I recall from my use years ago is that I moved away because of the # of keystrokes to do operations, having to open different files for different topics, and that one single set of notes couldn't be in more than one place.

OM fixes those things, in part by making each thing not a chunk of text but an entity (an object), where the data about it is stored in attributes which are known by the system to be boolean, url, numeric (with unit and type, eg 3 meters length), date, etc, so that in the (hopefully near) future those things can be used in calculations. More on that in #8 below.

Example: I can go from anywhere to "wife gift ideas" by holding down ESC briefly then hitting 5gd, which I can don't have to memorize because it's always on the screen in each menu as I go. Or, depending on where I am already, I might just hit a single keystroke or two. Or, quickly search from anywhere by typing "42gift ideas", browsing around, and ESC back to where I was. etc for any data I want: it's usually just a few keystrokes away unless I can't remember any of the natural-world-association nagivation paths and have to text search. I can get to my OM to-do list with 5daa. To my monthly financial reminders with 5ac6i but maybe that should be put in a shorter & more memorable path.

An example for sorting info: (I wished for things like this as a student.) I can very quickly create a text outline, adding stuff quickly and without thinking about the UI, as one would in drafting text for a paper. But in OM, I can then also move one paragraph (and all sub-contents in the outline) up one entry with 23, or down several entries with 25 or 26, etc. I can move an item up into the parent list with 8x8 or down into one that should become the parent, with at most 7y8x7. Those are automatic now. Then one could export it as a text outline to open in LibreOffice for fonts & printing. Or export it as html which is how I currently create the web site. (Maybe I should add some CSS support there).


2)
Same thing in many places: To link the current entity in at a completely different place, you copy part of its name (or id) to the clipboard, go to another place (or another open terminal tab), and hit 42/paste/a or such to insert it at the other place. Now it is in both places, or as many as you like. I use this heavily.


3)
Ease of learning: emacs is powerful and can have a heavy (but rewarding) learning curve. In OM, every operation is always on the screen, in a runtime-generated context-driven menu, and is often a single keystroke.


4)
Not sure what to add, except it's really nice.


5)
Ditto. I got tired of moving paragraphs around, just to want to move it back, or frequently reopening separate files (years ago), and with OM you just jump there or link/inlink with a keystroke or several.


6)
Not exactly what you asked, but: OM has a very different future vision for things like cloud use. And for enabling certain items to be marked for "sharing" with others, with ability to for others to watch/link/copy etc those items, so that we build up huge shared knowledge bases but still have individual control as far as desired. Sort of like one's own personal anki+wikipedia, but not losing the benefits of a global wikipedia+freebase. And more.

A *currently working* example of this is the ~"journal" feature, where OM can provide a (today very simple, raw) report on activity in the system by a date range: entities created or archived. This was partly to save me time & effort in remembering what I did for work reports, and partly to replace my other personal journals.

Another future example: the other message in this thread asked about SRS (e.g., Anki or org-drill), which I plan to implement in OM, by something like making each such item part of a "review" class (with multiple inheritance), and by virtue of that it will always have certain values (defaulting if not provided per instance) for some dates (an actual computable date, not text), and numbers etc. Then, a few chunks of code associated with that class, modifiable w/o recompile, and handled at runtime, which automatically become OM menu options and which let you mark an item to be reviewed again soon or how much later. (I didn't document this well; maybe I should; opinions welcome.) Same for periodic to-do items etc. I think org-mode can do those things now, but in OM they will be done not because of a lot of work to cleverly manipulate text, but because the data is *data* and we can run algorithms on it. This code association thing is a big part of my future intentions.


Granted, org-mode is more mature now, has more features and uses, but I think the internal premise of OM allows it to take on new challenges that would otherwise be impractical: efficient knowledge managed at an atomic level (not based on words or text), i.e., as computable data, and sharable, in the small or globally. More of that is in the "vision" stuff on the onemodel.org web site.

I originally reported here because I thought there could be interest to this community, but out of respect I wonder if further conversation should move to the onemodel.org list(s), unless the culture here allows going widely off-topic from org-mode use. :) I'm happy either way if others are.

Thanks!
Luke



reply via email to

[Prev in Thread] Current Thread [Next in Thread]