emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: luke call <luke350@onemodel.org>
To: Bingo UV <right.ho@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: "atomic knowledge" modeling tool
Date: Wed, 3 Feb 2016 11:22:22 -0700	[thread overview]
Message-ID: <56B2455E.7000706@onemodel.org> (raw)
In-Reply-To: <20160203224549.56b2001b@dhcppc15>

On 02/03/16 10:15, Bingo UV wrote:
> On Mon, 1 Feb 2016 15:15:03 -0700
> luke call <luke350@onemodel.org> wrote:
>
>> 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.
>
>     While I am no authority, I will present some information and
>     evidence about why one thing should be only in one place if its
>     purpose is consumption by human beings. It also matches my
>     personal experience - your mileage may vary:
>
> https://blog.evernote.com/blog/2015/12/11/evernote-and-the-brain-designing-creativity-workflows/
> ....
>  From this, I gather that tools promoting explicitly
> preemptive inter-connection between knowledge pieces like this
> one-model seems to be are not likely the best uses of
> one's own brain. Even attempts at exquisite tagging and
> cross-referencing within emacs org-mode are ill-advised.

Thanks for that comment and the link to his very thoughtful article. So, 
about multiple connections to the same thing and modeling knowledge with 
org-mode or any tool.  I think the author makes a good case for  using 
such connections, just not with tags.

In real life, the same entity is relevant to many contexts, and in 
representation it is useful to allow easy connections to & from those 
contexts.  For example, a entity representing a physical book is 
relevant to and can be thought of in connection with its location, its 
publisher, owner, topic, contents, author,  history, physical properties 
(newtonian physics...), purchase history, seller, account, book 
borrowers, etc.  Each of those things in turn has rich data and 
associations in the real world.  I think it usually far best not to 
duplicate the info about any entity or the knowledge of its existence in 
multiple places, because that leads to duplicate work and loss of 
utility, such as the ability to get the most out of all our knowledge, 
such as for various kinds of computation & rich queries.  This is 
fundamental in SQL theory for similar reasons.

(I see his point about tags, but partly disagree with the article author 
about those, because I use such thing with the intent to create all the 
ones I might think of using for a search, so it works in reverse: make 
the tag help me as I am, *not* make me work to remember the tag (who is 
servant vs. master).  And when making associations, use all those that 
work best for you.  Or just full-text search and periodic (hopefully 
easy/efficient) reorganization of ideas that are changing.)

Human memory improvement discussion often also recommends improving 
memory by creating associations. For me at least, any tool that is to be 
an aid to my mind benefits by allowing the same, so they work together 
well. In practice I go to the same entity by varying paths, depending on 
circumstance.

I do like the author's five numbered points (based on some skim & some 
reading).  He likes mind-maps, for example, which org-mode can 
approximate and OM subsumes (though not yet with diagrams: I'd like OM 
to generate those someday).  One has to decide what resonates, 
intuitively, as the author says.  In my efforts, I'm optimizing now for 
comprehensiveness and simplicity, and (hopefully very soon) for 
collaboration.

My answer to his desired "middle path" is to consider what *is* and 
model that, rather than creating paragraphs!  Instead, use entities with 
properties and relations, updating as understanding improves, which 
*really* helps with the problem of "loading and unloading" (I like how 
he put that).  I strongly feel as a knowledge worker that I have a core 
process of systematic improvement and all this is central to it.  *To 
model reality is the best way to work toward learning what is, _and_ to 
achieve his goals in optimizing "note design"* and to find what he calls 
"intelligent emergence": it cannot come optimally from being really good 
at managing huge piles of words, but rather managing knowledge which has 
one representation which we call words, others of images or animation, 
and still others of whatever we can create.

So an aim is to let recorded knowledge match reality as far as can be 
practical, with efficiency.

Thanks again for bringing this up.
-Luke

  reply	other threads:[~2016-02-03 18:22 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
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 [this message]
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=56B2455E.7000706@onemodel.org \
    --to=luke350@onemodel.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=right.ho@gmail.com \
    /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).