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
next prev parent 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).