emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: luke call <luke350@onemodel.org>
To: luke call <luke350@onemodel.org>, emacs-orgmode@gnu.org
Subject: Re: "atomic knowledge" modeling tool
Date: Mon, 1 Feb 2016 15:15:03 -0700	[thread overview]
Message-ID: <56AFD8E7.7060001@onemodel.org> (raw)
In-Reply-To: <87fuxeorpb.fsf@ucl.ac.uk>

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	other threads:[~2016-02-01 22:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 18:21 "atomic knowledge" modeling tool luke call
2016-01-31 12:32 ` Eric S Fraga
2016-02-01 22:15   ` luke call [this message]
2016-02-02  8:49     ` Eric S Fraga
2016-02-03  9:33     ` Marcin Borkowski
2016-02-03 14:47       ` luke call
2016-02-03 17:15     ` Bingo UV
2016-02-03 18:22       ` luke call
2016-01-31 15:37 ` Ramon Diaz-Uriarte
2016-02-01 21:25   ` luke call
2016-02-03  8:04     ` Ramon Diaz-Uriarte
2016-02-02  7:23 ` Robert Klein
2016-02-02 15:20   ` luke call
2016-02-16 14:14     ` Samuel Loury
2016-02-16 16:18       ` Eric S Fraga
2016-02-16 16:44       ` Nicolas Goaziou
2016-02-16 19:52         ` Eric S Fraga
2016-02-20 18:09         ` Samuel Loury
2016-02-21 11:21           ` Nicolas Goaziou
2016-02-22  9:04             ` Samuel Loury
2016-02-24 16:46               ` Eric S Fraga
2016-02-29 13:31                 ` Samuel Loury
2016-03-06 19:26                   ` Samuel Loury
2016-03-07 15:28                     ` Eric S Fraga
2016-03-10  8:01                       ` Samuel Loury
2016-03-18 21:44                       ` Samuel Loury

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56AFD8E7.7060001@onemodel.org \
    --to=luke350@onemodel.org \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).