org-mode for knowledge management

org-mode for knowledge management

[Louis]

Hi all,

I've been using org-mode for a variety of purposes for a few years. I find 
that it suffers from the same problem that other such tools do. The 
problem is me. I can't remember week to week how I may have classified 
some scrap of information. Did I drop it into notes/someproduct.org or was 
it procedures/someprocess.org?

While working through this, I've used #+INDEX: Topic!subtopic which helps 
but is not sufficiently granular.

I'm thinking about approaches using properties or drawers. Has any of you 
done something like this, or done something similar that I've not 
considered?


Thanks in advance,

Your rapidly graying, Louis

Re: org-mode for knowledge management

[Marcin Borkowski]

On 2014-10-10, at 00:17, Louis wrote:

> Hi all,
>
> I've been using org-mode for a variety of purposes for a few years. I find 
> that it suffers from the same problem that other such tools do. The 
> problem is me. I can't remember week to week how I may have classified 
> some scrap of information. Did I drop it into notes/someproduct.org or was 
> it procedures/someprocess.org?
>
> While working through this, I've used #+INDEX: Topic!subtopic which helps 
> but is not sufficiently granular.
>
> I'm thinking about approaches using properties or drawers. Has any of you 
> done something like this, or done something similar that I've not 
> considered?

Did you consider a /totally opposite/ approach?  I'm currently
reorganizing my org files (I had about 15 of them) so that I will be
able to cut them down to ≈ half that value.  The fewer, the better.  And
grep is your friend.  (I haven't yet got accustomed to C-c a s, but it's
really good.)

Also, if English is not your native language, consider making notes in
English.  Whether you like it or not, it has one huge advantage: it's
/simple/.  Almost no inflections, so grepping English texts is /much/
easier than, say, Polish (we have /a lot/ of inflections).  (In this
regard, Esperanto is even better, though personally I'm not fluent
enough in it to make my notes in Esperanto comfortably.)

> Thanks in advance,
>
> Your rapidly graying, Louis

Hth,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: org-mode for knowledge management

[Thomas S. Dye]

Aloha Louis,

Louis <lbmlist@hethcote.com> writes:

> Hi all,
>
> I've been using org-mode for a variety of purposes for a few years. I
> find that it suffers from the same problem that other such tools
> do. The problem is me. I can't remember week to week how I may have
> classified some scrap of information. Did I drop it into
> notes/someproduct.org or was it procedures/someprocess.org?
>
> While working through this, I've used #+INDEX: Topic!subtopic which
> helps but is not sufficiently granular.
>
> I'm thinking about approaches using properties or drawers. Has any of
> you done something like this, or done something similar that I've not
> considered?
>
>
> Thanks in advance,
>
> Your rapidly graying, Louis

Perhaps org-index in contrib would help?  

http://orgmode.org/worg/org-contrib/org-index.html

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-mode for knowledge management

[Louis]

On Thu, 9 Oct 2014, Thomas S. Dye wrote:

> Aloha Louis,
>
>>
>> Your rapidly graying, Louis
>
> Perhaps org-index in contrib would help?
>
> http://orgmode.org/worg/org-contrib/org-index.html
>

Thanks for the idea, it sounded promising, but it appears that it is no 
longer in contrb.

Re: org-mode for knowledge management

[Louis]

On Thu, 9 Oct 2014, Thomas S. Dye wrote:

> Aloha Louis,
>
> Louis <lbmlist@hethcote.com> writes:
>
>>
>> Your rapidly graying, Louis
>
> Perhaps org-index in contrib would help?
>
> http://orgmode.org/worg/org-contrib/org-index.html
>


Never mind,

http://orgmode.org/cgit.cgi/org-mode.git/plain/contrib/lisp/org-index.el

it's just not in the tarball.

Re: org-mode for knowledge management

[Daniel Clemente]

> >
> > I've been using org-mode for a variety of purposes for a few years. I find 
> > that it suffers from the same problem that other such tools do. The 
> > problem is me. I can't remember week to week how I may have classified 
> > some scrap of information. Did I drop it into notes/someproduct.org or was 
> > it procedures/someprocess.org?

1. Every information should have a single location, not two. Mix sections fast if you detect repetitions. Use links extensively (C-c l) to connect one header with another, specially after you get lost once. Don't bother too much about finding the right place at the first time, you'll eventually reorder or move headers to the correct place.

2. Use global search (C-a /), you can use regular expressions there. No need to use grep.

3. Use the package „helm“ to get fast access to all headers or to a subsection of headers (e.g. the ones you tag). E.g. I use <<<radio>>> to give important sections a title. After 1 key you start typing some letters, select with cursors, press ENTER and go to the header.

> 
> Also, if English is not your native language, consider making notes in
> English.  Whether you like it or not, it has one huge advantage: it's
> /simple/.  Almost no inflections, so grepping English texts is /much/
> easier than, say, Polish (we have /a lot/ of inflections).  (In this
> regard, Esperanto is even better, though personally I'm not fluent
> enough in it to make my notes in Esperanto comfortably.)
> 

  And I thought I was the only one taking notes in Esperanto! >700 Kb of my notes are in Esperanto. Sometimes I invent new words which later I don't find by searching, but after I do, I add the new variants of the title. It's great for defining strange concepts.
  Inflections are a minor problem in most languages, just use partial search or regexp (e.g. in Polish use „słow“ instead of „słowo“, „następn.*“ etc.) and you'll find everything. If you want inflection-free languages you'll need Indonesian, Chinese, … 
  But I wouldn't force taking notes in a language you don't like, just use the ones you like. („the ones“, in plural).


  Ĝis!
  
Daniel

Re: org-mode for knowledge management

[mbork]

On Fri, 10 Oct 2014 22:46:58 +0700, Daniel Clemente <n142857@gmail.com>
wrote:

> 1. Every information should have a single location, not two. Mix
sections
> fast if you detect repetitions. Use links extensively (C-c l) to connect
> one header with another, specially after you get lost once. Don't bother
> too much about finding the right place at the first time, you'll
eventually
> reorder or move headers to the correct place.

Yes (except that I don't use links).  But the principle is /very/ good:
"for each piece of information, you should know where to look for it: in
the place it /should/ be".

> 2. Use global search (C-a /), you can use regular expressions there. No
> need to use grep.

Yes.

> 3. Use the package „helm“ to get fast access to all headers or to a
> subsection of headers (e.g. the ones you tag). E.g. I use <<<radio>>> to
> give important sections a title. After 1 key you start typing some
letters,
> select with cursors, press ENTER and go to the header.

I don't use (nor want to start) helm; I use Ido, and I'm going to switch
to Icicles some day.  But the principle is true.

>> Also, if English is not your native language, consider making notes in
>> English.  Whether you like it or not, it has one huge advantage: it's
>> /simple/.  Almost no inflections, so grepping English texts is /much/
>> easier than, say, Polish (we have /a lot/ of inflections).  (In this
>> regard, Esperanto is even better, though personally I'm not fluent
>> enough in it to make my notes in Esperanto comfortably.)
> 
>   And I thought I was the only one taking notes in Esperanto! >700 Kb of
>   my notes are in Esperanto. Sometimes I invent new words which later I
>   don't find by searching, but after I do, I add the new variants of the
>   title. It's great for defining strange concepts.
>   Inflections are a minor problem in most languages, just use partial
>   search or regexp (e.g. in Polish use „słow“ instead of „słowo“,
>   „następn.*“ etc.) and you'll find everything. If you want
inflection-free
>   languages you'll need Indonesian, Chinese, …
>   But I wouldn't force taking notes in a language you don't like, just
use
>   the ones you like. („the ones“, in plural).

Well, I don't really use Esperanto (it's been like twenty years since
I've been fluent in it...), but I can see the benefits.

Also, in Polish it's not so simple: not only have you inflections, but
also some changes /inside/ the word (especially with vowels).  For
instance, plural genitive of "słowo" ("word") is "słów", so you need
more than e.g. "słow" - you need "sł[oó]w".  And this can become tedious
pretty quickly.

>   Ĝis!
>   
> Daniel

Ĝis!

Re: org-mode for knowledge management

[John Hendy]

On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente <n142857@gmail.com> wrote:
>> >
>> > I've been using org-mode for a variety of purposes for a few years. I find
>> > that it suffers from the same problem that other such tools do. The
>> > problem is me. I can't remember week to week how I may have classified
>> > some scrap of information. Did I drop it into notes/someproduct.org or was
>> > it procedures/someprocess.org?
>
> 1. Every information should have a single location, not two. Mix sections fast
> if you detect repetitions. Use links extensively (C-c l) to connect one header
> with another, specially after you get lost once. Don't bother too much about
> finding the right place at the first time, you'll eventually reorder or move
> headers to the correct place.

I'm curious about this. Is this a well-known recommendation/best
practice? I actually struggle with this a great deal. Often a bit of
research or testing for a specific project at work is very possibly
relevant to any number of future projects. So, working in product
development, I find it hard to decide what the best "single location"
is, and would love for it to act as though it were in multiple
locations.

When the current project is done, I'd like to archive everything
specifically related to it while keeping around the general knowledge
I've accumulated for use with future efforts.

Or is this what you mean by using links? Are you just saying that
individuals should not be copying the same text around in multiple
places?


Thanks,
John

[snip]

Re: org-mode for knowledge management

[Eric Abrahamsen]

John Hendy <jw.hendy@gmail.com> writes:

> On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente <n142857@gmail.com> wrote:
>>> >
>>> > I've been using org-mode for a variety of purposes for a few years. I find
>>> > that it suffers from the same problem that other such tools do. The
>>> > problem is me. I can't remember week to week how I may have classified
>>> > some scrap of information. Did I drop it into notes/someproduct.org or was
>>> > it procedures/someprocess.org?
>>
>> 1. Every information should have a single location, not two. Mix sections fast
>> if you detect repetitions. Use links extensively (C-c l) to connect one header
>> with another, specially after you get lost once. Don't bother too much about
>> finding the right place at the first time, you'll eventually reorder or move
>> headers to the correct place.
>
> I'm curious about this. Is this a well-known recommendation/best
> practice? I actually struggle with this a great deal. Often a bit of
> research or testing for a specific project at work is very possibly
> relevant to any number of future projects. So, working in product
> development, I find it hard to decide what the best "single location"
> is, and would love for it to act as though it were in multiple
> locations.

Isn't this what tags are good for, though? Sort of providing a secondary
structure to your information, orthogonal to Org's subtree structure?

> When the current project is done, I'd like to archive everything
> specifically related to it while keeping around the general knowledge
> I've accumulated for use with future efforts.

You could organize a project by subtree, but put generally-useful
research elsewhere, and tag that research by theme. Then give the
project subtree its own tag, but also add tags to the relevant research
themes. Open an Agenda with a "projecttag|themetag" tag search to see
both general research and project-specific stuff.

When the time comes, the project subtree gets archived, but the thematic
stuff stays.

Anyway, I'm sure you've considered all this, just curious what your
thoughts on tags are...

> Or is this what you mean by using links? Are you just saying that
> individuals should not be copying the same text around in multiple
> places?
>
>
> Thanks,
> John
>
> [snip]

Re: org-mode for knowledge management

[Daniel Clemente]

El Fri, 10 Oct 2014 16:48:39 -0500 John Hendy va escriure:
> 
> On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente <n142857@gmail.com> wrote:
> >> >
> >> > I've been using org-mode for a variety of purposes for a few years. I find
> >> > that it suffers from the same problem that other such tools do. The
> >> > problem is me. I can't remember week to week how I may have classified
> >> > some scrap of information. Did I drop it into notes/someproduct.org or was
> >> > it procedures/someprocess.org?
> >
> > 1. Every information should have a single location, not two. Mix sections fast
> > if you detect repetitions. Use links extensively (C-c l) to connect one header
> > with another, specially after you get lost once. Don't bother too much about
> > finding the right place at the first time, you'll eventually reorder or move
> > headers to the correct place.
> 
> I'm curious about this. Is this a well-known recommendation/best
> practice? 

  I find it it similar to the „Don't repeat yourself“ principle. But I was just explaining my experience.

> I actually struggle with this a great deal. Often a bit of
> research or testing for a specific project at work is very possibly
> relevant to any number of future projects. So, working in product
> development, I find it hard to decide what the best "single location"
> is, and would love for it to act as though it were in multiple
> locations.
> 
> When the current project is done, I'd like to archive everything
> specifically related to it while keeping around the general knowledge
> I've accumulated for use with future efforts.

  I use no tags or categories, just a clear and manual separation of concepts. E.g. it's not the same activity „I'm learning about database X“ and „I'm considering database X for project Y“, because notes from the first one go to Databases.org and notes from the second one to ProjectY.org. Clocking is different (even if I'm learning about X, I clock in Y if I'm doing it as part of a project).
  Therefore I try to keep project notes at a minimum, because they are dated and ephimeral, whereas the general knowledge accumulates in other files (one file per topic, encyclopedia-style).

> 
> Or is this what you mean by using links? Are you just saying that
> individuals should not be copying the same text around in multiple
> places?
> 

  Of course copy+paste is a nightmare to maintain (see: DRY). I am still forced to do it with some org tables which do complex calculations. I think org offers dynamic tables to apply the same process to different data sources, but it gets complex. I think there's no such thing as „templates“ where you change the base one and all uses of it (in all files) are automatically updated.

  About links: in org-mode they all look the same, but semantically there are many types, like:
- *is-a*: „this is a concrete implementation of [[that generic knowledge]]“
- *related*: „related to this is: [[that]]“
- *same-as*: „this and [[that]] are exactly the same topic, so write only under that header, not here“ ← this is poor man's transclusion, or more like „symbolic links“ in ext4. With it, a header seems to be present in many places at the same time; in reality the content is only in one place and the rest are links. The good thing is, it doesn't really matter /where/ exactly is that tree, because you'll find it anyway by following maximum 1 link. X can link to Y, or Y can link the X; what's important is that reading both X or Y you'll find exactly the same thing (not copy+pasted contents).

  So, it's all about finding a manual algorithm to organize things.


Daniel

Re: org-mode for knowledge management

[Brady Trainor]

Daniel Clemente <n142857@gmail.com> writes:

>   About links: in org-mode they all look the same, but semantically there are many types, like:
> - *is-a*: „this is a concrete implementation of [[that generic knowledge]]“
> - *related*: „related to this is: [[that]]“
> - *same-as*: „this and [[that]] are exactly the same topic, so write
> only under that header, not here“ ← this is poor man's transclusion,
> or more like „symbolic links“ in ext4. With it, a header seems to be
> present in many places at the same time; in reality the content is
> only in one place and the rest are links. The good thing is, it
> doesn't really matter /where/ exactly is that tree, because you'll
> find it anyway by following maximum 1 link. X can link to Y, or Y can
> link the X; what's important is that reading both X or Y you'll find
> exactly the same thing (not copy+pasted contents).
>
> Daniel

I don't think I am aware of the "*sameas*" type of link in org-mode, can
you give an example please? 

--
Brady

Re: org-mode for knowledge management

[Daniel Clemente]

El Sat, 11 Oct 2014 12:45:45 -0700 Brady Trainor va escriure:
> 
> >   About links: in org-mode they all look the same, but semantically there are many types, like:
> > […]
> > - *same-as*: „this and [[that]] are exactly the same topic, so write
> > only under that header, not here“ 
> > […]
> I don't think I am aware of the "*sameas*" type of link in org-mode, can
> you give an example please? 
> 

There's only 1 type of link between headers in org-mode; what's different is the way in which you use it.

* About web pages
** CSS
** HTML
*** Convert to other formats
**** convert to JSON
Use html2json
**** convert to PDF → see [[html_to_pdf]]
* About PDFs
** create them
*** from .odt
Click that icon.
*** from .html. id:html_to_pdf
There's this method…
*** from .tex


In this case, that „HTML→PDF“ section could live under the „web pages“ tree or under the „PDFs“ tree, and there's no difference because it's exactly the same information.
If you consider „link following“ as a trivial operation, you could say that that knowledge is accessible under both trees at the same time. It's not transclusion, but it works the same.

Note that in the example above, the „→ see …“ header must be empty of content. If you write inside, it's not a light link anymore, it's a header on its own.

Org-mode could offer this type of header built-in (a light header is a header which must link to another one and have no content), but you can do it with the current tools and a bit of care.

Re: org-mode for knowledge management

[John Hendy]

On Fri, Oct 10, 2014 at 9:53 PM, Eric Abrahamsen
<eric@ericabrahamsen.net> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente <n142857@gmail.com> wrote:
>>>> >
>>>> > I've been using org-mode for a variety of purposes for a few years. I find
>>>> > that it suffers from the same problem that other such tools do. The
>>>> > problem is me. I can't remember week to week how I may have classified
>>>> > some scrap of information. Did I drop it into notes/someproduct.org or was
>>>> > it procedures/someprocess.org?
>>>
>>> 1. Every information should have a single location, not two. Mix sections fast
>>> if you detect repetitions. Use links extensively (C-c l) to connect one header
>>> with another, specially after you get lost once. Don't bother too much about
>>> finding the right place at the first time, you'll eventually reorder or move
>>> headers to the correct place.
>>
>> I'm curious about this. Is this a well-known recommendation/best
>> practice? I actually struggle with this a great deal. Often a bit of
>> research or testing for a specific project at work is very possibly
>> relevant to any number of future projects. So, working in product
>> development, I find it hard to decide what the best "single location"
>> is, and would love for it to act as though it were in multiple
>> locations.
>
> Isn't this what tags are good for, though? Sort of providing a secondary
> structure to your information, orthogonal to Org's subtree structure?

Agreed, and have tried that, though that has issues as well, unless
I'm missing something (see below).

>
>> When the current project is done, I'd like to archive everything
>> specifically related to it while keeping around the general knowledge
>> I've accumulated for use with future efforts.
>
> You could organize a project by subtree, but put generally-useful
> research elsewhere, and tag that research by theme. Then give the
> project subtree its own tag, but also add tags to the relevant research
> themes. Open an Agenda with a "projecttag|themetag" tag search to see
> both general research and project-specific stuff.
>
> When the time comes, the project subtree gets archived, but the thematic
> stuff stays.

This is the bit I'm not sure about...

* project_a
** experiment about blah     :proj_name:theme:
[2014-10-11]

Did x, y, and z today. Will analyze results tomorrow.

[2014-10-12]

Wow. Interesting finding. This will help a lot and may be relevant to
future projects!

So... when I archive project_a, don't I lose the thematic information
from my experiment? This is sort of the conundrum I often find myself
in. I work in product development, and many of the difficulties,
experimental findings, or even contacts/information for a given
project seem like they'd be really helpful to recall/go back to for
future projects. The learning is uncovered only because I'm working on
launching *this* product... but isn't inherently relevant *only* to
this project.

I've migrated from one file per project like I used to do to the big
'ol one-file method (except for a contacts.org file and miscellany).
Thus, I tend to like to archive, but for whatever reason have an
aversion to agenda-ing on archived stuff. I find I only look in
archives when someone asks something really specific about a past
project and I think I have notes on it.

Anyway, that was my thought.

I saw Daniel replied as well; you both understand my struggle -- you
tackle it with tags and he's suggesting lots of links (more on that in
a sec).


Thanks!
John

>
> Anyway, I'm sure you've considered all this, just curious what your
> thoughts on tags are...
>
>> Or is this what you mean by using links? Are you just saying that
>> individuals should not be copying the same text around in multiple
>> places?
>>
>>
>> Thanks,
>> John
>>
>> [snip]
>
>

Re: org-mode for knowledge management

[John Hendy]

On Sat, Oct 11, 2014 at 6:36 AM, Daniel Clemente <n142857@gmail.com> wrote:
> El Fri, 10 Oct 2014 16:48:39 -0500 John Hendy va escriure:
>>
>> On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente <n142857@gmail.com> wrote:
>> >> >
>> >> > I've been using org-mode for a variety of purposes for a few years. I find
>> >> > that it suffers from the same problem that other such tools do. The
>> >> > problem is me. I can't remember week to week how I may have classified
>> >> > some scrap of information. Did I drop it into notes/someproduct.org or was
>> >> > it procedures/someprocess.org?
>> >
>> > 1. Every information should have a single location, not two. Mix sections fast
>> > if you detect repetitions. Use links extensively (C-c l) to connect one header
>> > with another, specially after you get lost once. Don't bother too much about
>> > finding the right place at the first time, you'll eventually reorder or move
>> > headers to the correct place.
>>
>> I'm curious about this. Is this a well-known recommendation/best
>> practice?
>
>   I find it it similar to the „Don't repeat yourself“ principle. But I was just explaining my experience.

Sure, and that makes sense. I just wanted to understand what you meant
by "everything has one correct place." We're on the same page now: not
copying text, but that doesn't mean something shouldn't be
referenced/linked to.

>
>> I actually struggle with this a great deal. Often a bit of
>> research or testing for a specific project at work is very possibly
>> relevant to any number of future projects. So, working in product
>> development, I find it hard to decide what the best "single location"
>> is, and would love for it to act as though it were in multiple
>> locations.
>>
>> When the current project is done, I'd like to archive everything
>> specifically related to it while keeping around the general knowledge
>> I've accumulated for use with future efforts.
>
>   I use no tags or categories, just a clear and manual separation of concepts. E.g. it's not the same activity „I'm learning about database X“ and „I'm considering database X for project Y“, because notes from the first one go to Databases.org and notes from the second one to ProjectY.org. Clocking is different (even if I'm learning about X, I clock in Y if I'm doing it as part of a project).
>   Therefore I try to keep project notes at a minimum, because they are dated and ephimeral, whereas the general knowledge accumulates in other files (one file per topic, encyclopedia-style).
>
>>
>> Or is this what you mean by using links? Are you just saying that
>> individuals should not be copying the same text around in multiple
>> places?
>>
>
>   Of course copy+paste is a nightmare to maintain (see: DRY). I am still forced to do it with some org tables which do complex calculations. I think org offers dynamic tables to apply the same process to different data sources, but it gets complex. I think there's no such thing as „templates“ where you change the base one and all uses of it (in all files) are automatically updated.
>
>   About links: in org-mode they all look the same, but semantically there are many types, like:
> - *is-a*: „this is a concrete implementation of [[that generic knowledge]]“
> - *related*: „related to this is: [[that]]“
> - *same-as*: „this and [[that]] are exactly the same topic, so write only under that header, not here“ ← this is poor man's transclusion, or more like „symbolic links“ in ext4. With it, a header seems to be present in many places at the same time; in reality the content is only in one place and the rest are links. The good thing is, it doesn't really matter /where/ exactly is that tree, because you'll find it anyway by following maximum 1 link. X can link to Y, or Y can link the X; what's important is that reading both X or Y you'll find exactly the same thing (not copy+pasted contents).
>
>   So, it's all about finding a manual algorithm to organize things

This is generally what I've tried to do, though I find this is
cumbersome as I often use subtrees for more report-style/narrative
analyses of data and experiments. Thus I don't find it as simple as
your example to Brady with the PDF/HTML info, which is more basic. As
I write this, I'm thinking I could probably still do this...

For an example, let's say I'm making plastic widgets and we've been
running a series of injection mold trials with a manufacturer. Some
really novel understanding comes about with respect to part
uniformity, extruder/die temperature, cooling time, holding pressure,
etc. I think this is awesome general knowledge. But I'm documenting
our learning in an experimental report for export and upload to my
company's internal technical report repo.

My initial thought was that links this way would get in the way... but
I suppose now I could be writing along and create a link to the
nearest headline in the report, then go to some other tree and insert
a link to that headline with some note about the gist of the
understanding or keywords for the future me trying to re-find that
tidbit.

What I'm often torn about is re-writing the
learning/understanding/summary in a more general way since how it
usually arises is laden with specific details for *this*
product/project, whereas the information I want to retain is about how
I see the new understanding more generally.

Does that make sense?

John

.
>
>
> Daniel

Re: org-mode for knowledge management

[Daniel Clemente]

> […]
> uniformity, extruder/die temperature, cooling time, holding pressure,
> etc. I think this is awesome general knowledge. But I'm documenting
> our learning in an experimental report for export and upload to my
> company's internal technical report repo.

  I find it very different to write notes for yourself and to write for an audience. In a report you need to follow a structure, you need to choose a particular natural language, you need to explain things that might be obvious for you, you cannot change topic, … Whereas in notes, you're free. Therefore I think it makes sense to have two different places for both.


> What I'm often torn about is re-writing the
> learning/understanding/summary in a more general way since how it
> usually arises is laden with specific details for *this*
> product/project, whereas the information I want to retain is about how
> I see the new understanding more generally.

  … However, I don't consider that rewriting (specific→general) you mention as a necessary task or a burden (I don't do it), because in your notes (generic knowledge) you can simply refer to the specific one (e.g.: „see what I did in this case ([[link_to_the_report]])“.). A header with 1 or 2 or N links to specific reports is a good start before continue focusing on other generic-knowledge topics.
  So you decide where you will work the most (either in the specific reports or in the generic knowledge) and then the other can refer to it.
  I do it like that. E.g. I'm not writing in my generic notes a „code style guide“ because I did it already in project X, so I add knowledge in projectX.org and just link to it. If some particular knowledge grows too big for that projectX_code_style, I develop it in my generic notes (another file, project-unrelated).


> >   Of course copy+paste is a nightmare to maintain (see: DRY). I am still forced to do it with some org tables which do complex calculations. I think org offers dynamic tables to apply the same process to different data sources, but it gets complex. I think there's no such thing as „templates“ where you change the base one and all uses of it (in all files) are automatically updated.
> >
> >   About links: in org-mode they all look the same, but semantically there are many types, like:
> > - *is-a*: „this is a concrete implementation of [[that generic knowledge]]“
> > - *related*: „related to this is: [[that]]“
> > - *same-as*: „this and [[that]] are exactly the same topic, so write only under that header, not here“ ← this is poor man's transclusion, or more like „symbolic links“ in ext4. With it, a header seems to be present in many places at the same time; in reality the content is only in one place and the rest are links. The good thing is, it doesn't really matter /where/ exactly is that tree, because you'll find it anyway by following maximum 1 link. X can link to Y, or Y can link the X; what's important is that reading both X or Y you'll find exactly the same thing (not copy+pasted contents).
> >
> >   So, it's all about finding a manual algorithm to organize things
> 
> This is generally what I've tried to do, though I find this is
> cumbersome as I often use subtrees for more report-style/narrative
> analyses of data and experiments. Thus I don't find it as simple as
> your example to Brady with the PDF/HTML info, which is more basic. As
> I write this, I'm thinking I could probably still do this...
> 
> For an example, let's say I'm making plastic widgets and we've been
> running a series of injection mold trials with a manufacturer. Some
> really novel understanding comes about with respect to part
> uniformity, extruder/die temperature, cooling time, holding pressure,
> etc. I think this is awesome general knowledge. But I'm documenting
> our learning in an experimental report for export and upload to my
> company's internal technical report repo.
> 
> My initial thought was that links this way would get in the way... but
> I suppose now I could be writing along and create a link to the
> nearest headline in the report, then go to some other tree and insert
> a link to that headline with some note about the gist of the
> understanding or keywords for the future me trying to re-find that
> tidbit.
> 

  Note that:
- I don't suggest you abuse links and link every header. You can link to interesting topics. Like in Wikipedia: you /could/ link every word, but it makes sense to link only interesting information (only: in WP they link too much because they don't know what exactly will be interesting to the reader; but in your notes, you know already which links will you need in the future).
- In my example, the link meant „this is the same as that“, and I think this is always a basic concept, even in complex scenarios. In your case, your link may mean something different (like: „this heading is a specific wording of that knowledge“)
- That header with empty contents that says „for this, don't look here but look there: [[there]]“ is only one line and doesn't get in the way. And you use it only when you need it (e.g. when you ended in the wrong place after a text search and want to link to the good one for the next time).
  

Re: org-mode for knowledge management

[Eric Abrahamsen]

John Hendy <jw.hendy@gmail.com> writes:

> On Fri, Oct 10, 2014 at 9:53 PM, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
>> John Hendy <jw.hendy@gmail.com> writes:
>>
>>> On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente <n142857@gmail.com> wrote:
>>>>> >
>>>>> > I've been using org-mode for a variety of purposes for a few years. I find
>>>>> > that it suffers from the same problem that other such tools do. The
>>>>> > problem is me. I can't remember week to week how I may have classified
>>>>> > some scrap of information. Did I drop it into notes/someproduct.org or was
>>>>> > it procedures/someprocess.org?
>>>>
>>>> 1. Every information should have a single location, not two. Mix sections fast
>>>> if you detect repetitions. Use links extensively (C-c l) to connect one header
>>>> with another, specially after you get lost once. Don't bother too much about
>>>> finding the right place at the first time, you'll eventually reorder or move
>>>> headers to the correct place.
>>>
>>> I'm curious about this. Is this a well-known recommendation/best
>>> practice? I actually struggle with this a great deal. Often a bit of
>>> research or testing for a specific project at work is very possibly
>>> relevant to any number of future projects. So, working in product
>>> development, I find it hard to decide what the best "single location"
>>> is, and would love for it to act as though it were in multiple
>>> locations.
>>
>> Isn't this what tags are good for, though? Sort of providing a secondary
>> structure to your information, orthogonal to Org's subtree structure?
>
> Agreed, and have tried that, though that has issues as well, unless
> I'm missing something (see below).
>
>>
>>> When the current project is done, I'd like to archive everything
>>> specifically related to it while keeping around the general knowledge
>>> I've accumulated for use with future efforts.
>>
>> You could organize a project by subtree, but put generally-useful
>> research elsewhere, and tag that research by theme. Then give the
>> project subtree its own tag, but also add tags to the relevant research
>> themes. Open an Agenda with a "projecttag|themetag" tag search to see
>> both general research and project-specific stuff.
>>
>> When the time comes, the project subtree gets archived, but the thematic
>> stuff stays.
>
> This is the bit I'm not sure about...
>
> * project_a
> ** experiment about blah     :proj_name:theme:
> [2014-10-11]
>
> Did x, y, and z today. Will analyze results tomorrow.
>
> [2014-10-12]
>
> Wow. Interesting finding. This will help a lot and may be relevant to
> future projects!
>
> So... when I archive project_a, don't I lose the thematic information
> from my experiment? This is sort of the conundrum I often find myself
> in. I work in product development, and many of the difficulties,
> experimental findings, or even contacts/information for a given
> project seem like they'd be really helpful to recall/go back to for
> future projects. The learning is uncovered only because I'm working on
> launching *this* product... but isn't inherently relevant *only* to
> this project.

I guess my assumption is that the "interesting finding" bit would be its
own heading, and would *not* live in the project_a subtree at all, but
rather in a different subtree that was dedicated to whatever the "theme"
is. So the heading for the experiment would just be about the experiment
itself, and you'd make a new "note" about the generally-useful finding
elsewhere.

Perhaps both links and tags are what you're after then: you could leave
a link to the general finding inside "experiment about blah" (to remind
yourself you took that note), but also use the tags to open Agendas on
both project and theme, so you can see all the relevant information in
one place.

Dunno!

> I've migrated from one file per project like I used to do to the big
> 'ol one-file method (except for a contacts.org file and miscellany).
> Thus, I tend to like to archive, but for whatever reason have an
> aversion to agenda-ing on archived stuff. I find I only look in
> archives when someone asks something really specific about a past
> project and I think I have notes on it.
>
> Anyway, that was my thought.
>
> I saw Daniel replied as well; you both understand my struggle -- you
> tackle it with tags and he's suggesting lots of links (more on that in
> a sec).
>
>
> Thanks!
> John
>
>>
>> Anyway, I'm sure you've considered all this, just curious what your
>> thoughts on tags are...
>>
>>> Or is this what you mean by using links? Are you just saying that
>>> individuals should not be copying the same text around in multiple
>>> places?
>>>
>>>
>>> Thanks,
>>> John
>>>
>>> [snip]
>>
>>

Re: org-mode for knowledge management

[Daniel Clemente]

El Mon, 13 Oct 2014 10:42:28 +0800 Eric Abrahamsen va escriure:
> >
> > This is the bit I'm not sure about...
> >
> > * project_a
> > ** experiment about blah     :proj_name:theme:
> > [2014-10-11]
> >
> > Did x, y, and z today. Will analyze results tomorrow.
> >
> > [2014-10-12]
> >
> > Wow. Interesting finding. This will help a lot and may be relevant to
> > future projects!
> >
> …
> 
> Perhaps both links and tags are what you're after then: you could leave
> a link to the general finding inside "experiment about blah" (to remind
> yourself you took that note), but also use the tags to open Agendas on
> both project and theme, so you can see all the relevant information in
> one place.
> 


> > * project_a
> > ** experiment about blah     :proj_name:theme:

  I think it's crazy to use topics as tags. How many topics/themes are there? Wikipedia counts many million. Names of topic are very subjective. Topics are often mixed, split apart, refined, renamed, grouped in supertopics, …
  In org it's easy to remodel hierarchical headers but it's not easy to remodel tags (much less, hierarchical tags).

  So rather than:

** some construction          :plastics_engineering:


  I would have:

Engineering.org:
* Plastics
* Houses
* …


  I understand you use tags and „tag search“ to be able to look for bits of a particular topic in a file which is not related to the topic.
  It would be better to have a tag that in addition links to a particular tree. With that you'd have the freedom of tagging anything and the flexibility of headers.

  Some brainstorming about how to link tags with headers: Two options:

1) There is a main tag in a header, and the other tags link to it (with C-c C-o you navigate to the main tag).

proj1.org:
** some construction          :plastics_engineering:

Engineering.org:          :<<<plastics_engineering>>>:
* Plastics
* Houses
* …


2) You use links and you ask for backlinks

proj1.org:
** some construction [link to P]

Engineering.org:
* Plastics
  :ID: 1231212311122
* Houses
* …

And then… a key to *search for links to a header* („backlinks“). Can org do this now?.
E.g. you go to „Plastics“ and you search „all the backlinks found in proj1.org“. Then you have the generic knowledge and in addition all the bits of specific knowledge about that topic.


Maybe this is already possible… Whether it's useful, I don't know.

Re: org-mode for knowledge management

[Samuel Wales]

(defun alpha-org-what-links-here ()
  "Show all links that point to the current node.  Also show the
node itself.

This makes id links quasi-bidirectional."
  (interactive)
  (let ((org-agenda-files (alpha-org-all-org-files
                           :archive t
                           :text-search-extra t))
        ;; turn off redundancy
        ;;   fixme probably going to be redone
        org-agenda-text-search-extra-files)
    (org-search-view nil (org-entry-get nil "ID" t))))


On 10/12/14, Daniel Clemente <n142857@gmail.com> wrote:
> El Mon, 13 Oct 2014 10:42:28 +0800 Eric Abrahamsen va escriure:
>> >
>> > This is the bit I'm not sure about...
>> >
>> > * project_a
>> > ** experiment about blah     :proj_name:theme:
>> > [2014-10-11]
>> >
>> > Did x, y, and z today. Will analyze results tomorrow.
>> >
>> > [2014-10-12]
>> >
>> > Wow. Interesting finding. This will help a lot and may be relevant to
>> > future projects!
>> >
>> …
>>
>> Perhaps both links and tags are what you're after then: you could leave
>> a link to the general finding inside "experiment about blah" (to remind
>> yourself you took that note), but also use the tags to open Agendas on
>> both project and theme, so you can see all the relevant information in
>> one place.
>>
>
>
>> > * project_a
>> > ** experiment about blah     :proj_name:theme:
>
>   I think it's crazy to use topics as tags. How many topics/themes are
> there? Wikipedia counts many million. Names of topic are very subjective.
> Topics are often mixed, split apart, refined, renamed, grouped in
> supertopics, …
>   In org it's easy to remodel hierarchical headers but it's not easy to
> remodel tags (much less, hierarchical tags).
>
>   So rather than:
>
> ** some construction          :plastics_engineering:
>
>
>   I would have:
>
> Engineering.org:
> * Plastics
> * Houses
> * …
>
>
>   I understand you use tags and „tag search“ to be able to look for bits of
> a particular topic in a file which is not related to the topic.
>   It would be better to have a tag that in addition links to a particular
> tree. With that you'd have the freedom of tagging anything and the
> flexibility of headers.
>
>   Some brainstorming about how to link tags with headers: Two options:
>
> 1) There is a main tag in a header, and the other tags link to it (with C-c
> C-o you navigate to the main tag).
>
> proj1.org:
> ** some construction          :plastics_engineering:
>
> Engineering.org:          :<<<plastics_engineering>>>:
> * Plastics
> * Houses
> * …
>
>
> 2) You use links and you ask for backlinks
>
> proj1.org:
> ** some construction [link to P]
>
> Engineering.org:
> * Plastics
>   :ID: 1231212311122
> * Houses
> * …
>
> And then… a key to *search for links to a header* („backlinks“). Can org do
> this now?.
> E.g. you go to „Plastics“ and you search „all the backlinks found in
> proj1.org“. Then you have the generic knowledge and in addition all the bits
> of specific knowledge about that topic.
>
>
> Maybe this is already possible… Whether it's useful, I don't know.
>
>


-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: org-mode for knowledge management

[Brett Viren]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

Hi Louis,

Louis <lbmlist@hethcote.com> writes:

> I've been using org-mode for a variety of purposes for a few years. I
> find that it suffers from the same problem that other such tools
> do. The problem is me. I can't remember week to week how I may have
> classified some scrap of information. Did I drop it into
> notes/someproduct.org or was it procedures/someprocess.org?

I hear you.  My strategy so far has been: just write org content and an
ideal lookup solution will eventually be found (via threads like this
one!).

This weekend I took a first step and *finally* got agenda-based
searching to work.  For better or worse, my setup intentionally spreads
org content over a few areas:

For a few explicit, "global" files (eg, todo.org)
  ~/org/*.org          

For daily, private notes:
  ~/org/web/notes/<YYYY>/<MM>/<DD>/notes.org   

For a wiki-like blog / knowledge bank:
  ~/org-pub/topics/<TOPIC>/index.org

By default, my attempts with org agenda search was not finding files in
these areas.  Particularly the latter two were difficult for me to
figure out how to tell org about.  The final solution was to walk these
directories at initialization time and add all .org files found to
org-agenda-text-search-extra-files.  Here is the most concise way to do
that which I found after various searches:

(require 'find-lisp)
(setq  
 org-agenda-files (list "~/org")
 org-agenda-text-search-extra-files 
 (append
  (find-lisp-find-files "~/org-pub/topics/" "\\.org$")
  (find-lisp-find-files "~/org/web/notes/" "\\.org$"))
)

If anyone knows better ways to do this, I'm all ears.  I'm particularly
wondering how long-running org sessions will handle newly created topics
or notes in this setup.

-Brett.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

Re: org-mode for knowledge management

[Louis]

On Thu, 9 Oct 2014, Thomas S. Dye wrote:

> Aloha Louis,
>
> Louis <lbmlist@hethcote.com> writes:
>
>> Hi all,
>>
>> I've been using org-mode for a variety of purposes for a few years. I
>> find that it suffers from the same problem that other such tools
>> do. The problem is me. I can't remember week to week how I may have
>> classified some scrap of information. Did I drop it into
>> notes/someproduct.org or was it procedures/someprocess.org?
>>
>
> Perhaps org-index in contrib would help?
>
> http://orgmode.org/worg/org-contrib/org-index.html
>
> hth,
> Tom

It looks promising. I haven't figured out the trick of it yet, though.

Do you go to the target node and do an org-index link, then goto the
index table and do an org-index fill?

Anybody have some usage tips?


Louis



>
> -- 
> Thomas S. Dye
> http://www.tsdye.com
>
>
>

Re: org-mode for knowledge management

[Thomas S. Dye]

Louis <lbmlist@hethcote.com> writes:

> On Thu, 9 Oct 2014, Thomas S. Dye wrote:
>
>> Aloha Louis,
>>
>> Louis <lbmlist@hethcote.com> writes:
>>
>>> Hi all,
>>>
>>> I've been using org-mode for a variety of purposes for a few years. I
>>> find that it suffers from the same problem that other such tools
>>> do. The problem is me. I can't remember week to week how I may have
>>> classified some scrap of information. Did I drop it into
>>> notes/someproduct.org or was it procedures/someprocess.org?
>>>
>>
>> Perhaps org-index in contrib would help?
>>
>> http://orgmode.org/worg/org-contrib/org-index.html
>>
>> hth,
>> Tom
>
> It looks promising. I haven't figured out the trick of it yet, though.
>
> Do you go to the target node and do an org-index link, then goto the
> index table and do an org-index fill?
>
> Anybody have some usage tips?

Does the working example
(http://orgmode.org/worg/org-contrib/org-index.html#sec-5) work for you?

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-mode for knowledge management

[Louis]

On Mon, 13 Oct 2014, Thomas S. Dye wrote:

> Does the working example
> (http://orgmode.org/worg/org-contrib/org-index.html#sec-5) work for you?
>

No, actually it doesn't. The node:

    * A working example
    This node contains a simple setup, which can be used to explore
    org-index. Further below there is also
    [[id:848c6d2a-6e8b-4c93-8481-19e6db7e6ca8][A sample for an index table]].

refers to an id that doesn't exist.

If you take the #+BEGIN_EXAMPLE, #+END_EXAMPLE out from around the list 
and add the properties/ID drawer, then the "C-c i bar[RET]" does bring 
up the *org-index-occur* buffer. Typing [RET] wont take you to the node
referenced by ref R2, because it doesn't exist anywhere.

It shows you how to search, but not how to create a reference to anything.

Still trying various approaches...




> hth,
> Tom
>
> -- 
> Thomas S. Dye
> http://www.tsdye.com
>
>

Re: org-mode for knowledge management

[Eric Abrahamsen]

Daniel Clemente <n142857@gmail.com> writes:

> El Mon, 13 Oct 2014 10:42:28 +0800 Eric Abrahamsen va escriure:
>> >
>> > This is the bit I'm not sure about...
>> >
>> > * project_a
>> > ** experiment about blah     :proj_name:theme:
>> > [2014-10-11]
>> >
>> > Did x, y, and z today. Will analyze results tomorrow.
>> >
>> > [2014-10-12]
>> >
>> > Wow. Interesting finding. This will help a lot and may be relevant to
>> > future projects!
>> >
>> …
>> 
>> Perhaps both links and tags are what you're after then: you could leave
>> a link to the general finding inside "experiment about blah" (to remind
>> yourself you took that note), but also use the tags to open Agendas on
>> both project and theme, so you can see all the relevant information in
>> one place.
>> 
>
>
>> > * project_a
>> > ** experiment about blah     :proj_name:theme:
>
>   I think it's crazy to use topics as tags. How many topics/themes are
> there? Wikipedia counts many million. Names of topic are very
> subjective. Topics are often mixed, split apart, refined, renamed,
> grouped in supertopics, …
>   In org it's easy to remodel hierarchical headers but it's not easy to remodel tags (much less, hierarchical tags).

Personally, I'm not trying to model all of human knowledge in my Org
files! I suppose if you were an academic researcher it might be a bigger
issue, but I count 71 different tags in my agenda files, and I don't
feel overwhelmed. You can get a bit of tag hierarchy with tag groups,
but admittedly only a bit.

>   So rather than:
>
> ** some construction          :plastics_engineering:
>
>
>   I would have:
>
> Engineering.org:
> * Plastics
> * Houses
> * …
>
>
>   I understand you use tags and „tag search“ to be able to look for
> bits of a particular topic in a file which is not related to the
> topic.
>   It would be better to have a tag that in addition links to a
> particular tree. With that you'd have the freedom of tagging anything
> and the flexibility of headers.
>
>   Some brainstorming about how to link tags with headers: Two options:
>
> 1) There is a main tag in a header, and the other tags link to it (with C-c C-o you navigate to the main tag).
>
> proj1.org:
> ** some construction          :plastics_engineering:
>
> Engineering.org:          :<<<plastics_engineering>>>:
> * Plastics
> * Houses
> * …
>
>
> 2) You use links and you ask for backlinks
>
> proj1.org:
> ** some construction [link to P]
>
> Engineering.org:
> * Plastics
>   :ID: 1231212311122
> * Houses
> * …
>
> And then… a key to *search for links to a header* („backlinks“). Can org do this now?.
> E.g. you go to „Plastics“ and you search „all the backlinks found in
> proj1.org“. Then you have the generic knowledge and in addition all
> the bits of specific knowledge about that topic.
>
>
> Maybe this is already possible… Whether it's useful, I don't know.

To my knowledge, no one's implemented a reverse link lookup, but it
should certainly be possible. Using the <<<foo>>> link notation as a
tag, however, would probably end up being more work (and more confusing)
than it's worth.

E

Re: org-mode for knowledge management

[John Hendy]

On Sun, Oct 12, 2014 at 2:48 AM, Daniel Clemente <n142857@gmail.com> wrote:
>
>> […]
>> uniformity, extruder/die temperature, cooling time, holding pressure,
>> etc. I think this is awesome general knowledge. But I'm documenting
>> our learning in an experimental report for export and upload to my
>> company's internal technical report repo.
>
>   I find it very different to write notes for yourself and to write for an audience. In a report you need to follow a structure, you need to choose a particular natural language, you need to explain things that might be obvious for you, you cannot change topic, … Whereas in notes, you're free. Therefore I think it makes sense to have two different places for both.

In general I'd say that's true, though I'm often doing analysis as
part of a project team. It's easier to just do it once, turn scattered
phrases into an actual narrative/walkthrough, and not have to re-write
it more formally later. I've taken to this after making little
headlines for myself and then having to piece together bits and pieces
(tables, plots, commentary) into something I can share with the team.

So, my situation may be a bit different as I'm strictly speaking about
using org to manage work-related knowledge (which generally is not
occurring in a black hole and thus must have some degree of polish).

>> What I'm often torn about is re-writing the
>> learning/understanding/summary in a more general way since how it
>> usually arises is laden with specific details for *this*
>> product/project, whereas the information I want to retain is about how
>> I see the new understanding more generally.
>
>   … However, I don't consider that rewriting (specific→general) you mention as a necessary task or a burden (I don't do it), because in your notes (generic knowledge) you can simply refer to the specific one (e.g.: „see what I did in this case ([[link_to_the_report]])“.). A header with 1 or 2 or N links to specific reports is a good start before continue focusing on other generic-knowledge topics.
>   So you decide where you will work the most (either in the specific reports or in the generic knowledge) and then the other can refer to it.

I like that, and think it makes sense.

* Generic knowledge tree
** Relevant sub-topic
*** Something
Cool finding happened related to work on x, in that blah. See [[link]] for more.

>   I do it like that. E.g. I'm not writing in my generic notes a „code style guide“ because I did it already in project X, so I add knowledge in projectX.org and just link to it. If some particular knowledge grows too big for that projectX_code_style, I develop it in my generic notes (another file, project-unrelated).

>> >   Of course copy+paste is a nightmare to maintain (see: DRY). I am still forced to do it with some org tables which do complex calculations. I think org offers dynamic tables to apply the same process to different data sources, but it gets complex. I think there's no such thing as „templates“ where you change the base one and all uses of it (in all files) are automatically updated.
>> >
>> >   About links: in org-mode they all look the same, but semantically there are many types, like:
>> > - *is-a*: „this is a concrete implementation of [[that generic knowledge]]“
>> > - *related*: „related to this is: [[that]]“
>> > - *same-as*: „this and [[that]] are exactly the same topic, so write only under that header, not here“ ← this is poor man's transclusion, or more like „symbolic links“ in ext4. With it, a header seems to be present in many places at the same time; in reality the content is only in one place and the rest are links. The good thing is, it doesn't really matter /where/ exactly is that tree, because you'll find it anyway by following maximum 1 link. X can link to Y, or Y can link the X; what's important is that reading both X or Y you'll find exactly the same thing (not copy+pasted contents).
>> >
>> >   So, it's all about finding a manual algorithm to organize things
>>
>> This is generally what I've tried to do, though I find this is
>> cumbersome as I often use subtrees for more report-style/narrative
>> analyses of data and experiments. Thus I don't find it as simple as
>> your example to Brady with the PDF/HTML info, which is more basic. As
>> I write this, I'm thinking I could probably still do this...
>>
>> For an example, let's say I'm making plastic widgets and we've been
>> running a series of injection mold trials with a manufacturer. Some
>> really novel understanding comes about with respect to part
>> uniformity, extruder/die temperature, cooling time, holding pressure,
>> etc. I think this is awesome general knowledge. But I'm documenting
>> our learning in an experimental report for export and upload to my
>> company's internal technical report repo.
>>
>> My initial thought was that links this way would get in the way... but
>> I suppose now I could be writing along and create a link to the
>> nearest headline in the report, then go to some other tree and insert
>> a link to that headline with some note about the gist of the
>> understanding or keywords for the future me trying to re-find that
>> tidbit.
>>
>
>   Note that:
> - I don't suggest you abuse links and link every header. You can link to interesting topics. Like in Wikipedia: you /could/ link every word, but it makes sense to link only interesting information (only: in WP they link too much because they don't know what exactly will be interesting to the reader; but in your notes, you know already which links will you need in the future).
> - In my example, the link meant „this is the same as that“, and I think this is always a basic concept, even in complex scenarios. In your case, your link may mean something different (like: „this heading is a specific wording of that knowledge“)
> - That header with empty contents that says „for this, don't look here but look there: [[there]]“ is only one line and doesn't get in the way. And you use it only when you need it (e.g. when you ended in the wrong place after a text search and want to link to the good one for the next time).
>

Agreed, and like both points. I'm due for an overhaul of archiving and
re-arranging at some point, and will likely try to use what I've
accumulated so far in an effort to try and map a better structure that
works. I originally tried to do a heading per project, with sub
headings for stuff like team meeting minutes, experiments or simply
daily journals/progress, research into manufacturers or raw materials,
etc.

Then I got sick of always filing daily stuff in with the project
itself and took to a date tree instead. Mostly, this was just easier
and avoided having to categorize everything all the time. Put it under
what day it happened. Simple. Really specific stuff still ended up
under the project, but now things are separated into knowledge tidbits
for the project (project tree) and actions taken for the project (date
tree, along with actions taken for everything else). Maybe that's
fine... just haven't settled on whether I like it or not.



Thanks for the dialog!
John

Re: org-mode for knowledge management

[Daniel Clemente]

Thanks, that's a very simple way to search backlinks! I didn't know about org-search-view.


El Sun, 12 Oct 2014 22:17:27 -0700 Samuel Wales va escriure:
> 
> (defun alpha-org-what-links-here ()
>   "Show all links that point to the current node.  Also show the
> node itself.
> 
> This makes id links quasi-bidirectional."
>   (interactive)
>   (let ((org-agenda-files (alpha-org-all-org-files
>                            :archive t
>                            :text-search-extra t))
>         ;; turn off redundancy
>         ;;   fixme probably going to be redone
>         org-agenda-text-search-extra-files)
>     (org-search-view nil (org-entry-get nil "ID" t))))
> 
> 
> On 10/12/14, Daniel Clemente <n142857@gmail.com> wrote:
> > El Mon, 13 Oct 2014 10:42:28 +0800 Eric Abrahamsen va escriure:
> >> >
> >> > This is the bit I'm not sure about...
> >> >
> >> > * project_a
> >> > ** experiment about blah     :proj_name:theme:
> >> > [2014-10-11]
> >> >
> >> > Did x, y, and z today. Will analyze results tomorrow.
> >> >
> >> > [2014-10-12]
> >> >
> >> > Wow. Interesting finding. This will help a lot and may be relevant to
> >> > future projects!
> >> >
> >> …
> >>
> >> Perhaps both links and tags are what you're after then: you could leave
> >> a link to the general finding inside "experiment about blah" (to remind
> >> yourself you took that note), but also use the tags to open Agendas on
> >> both project and theme, so you can see all the relevant information in
> >> one place.
> >>
> >
> >
> >> > * project_a
> >> > ** experiment about blah     :proj_name:theme:
> >
> >   I think it's crazy to use topics as tags. How many topics/themes are
> > there? Wikipedia counts many million. Names of topic are very subjective.
> > Topics are often mixed, split apart, refined, renamed, grouped in
> > supertopics, …
> >   In org it's easy to remodel hierarchical headers but it's not easy to
> > remodel tags (much less, hierarchical tags).
> >
> >   So rather than:
> >
> > ** some construction          :plastics_engineering:
> >
> >
> >   I would have:
> >
> > Engineering.org:
> > * Plastics
> > * Houses
> > * …
> >
> >
> >   I understand you use tags and „tag search“ to be able to look for bits of
> > a particular topic in a file which is not related to the topic.
> >   It would be better to have a tag that in addition links to a particular
> > tree. With that you'd have the freedom of tagging anything and the
> > flexibility of headers.
> >
> >   Some brainstorming about how to link tags with headers: Two options:
> >
> > 1) There is a main tag in a header, and the other tags link to it (with C-c
> > C-o you navigate to the main tag).
> >
> > proj1.org:
> > ** some construction          :plastics_engineering:
> >
> > Engineering.org:          :<<<plastics_engineering>>>:
> > * Plastics
> > * Houses
> > * …
> >
> >
> > 2) You use links and you ask for backlinks
> >
> > proj1.org:
> > ** some construction [link to P]
> >
> > Engineering.org:
> > * Plastics
> >   :ID: 1231212311122
> > * Houses
> > * …
> >
> > And then… a key to *search for links to a header* („backlinks“). Can org do
> > this now?.
> > E.g. you go to „Plastics“ and you search „all the backlinks found in
> > proj1.org“. Then you have the generic knowledge and in addition all the bits
> > of specific knowledge about that topic.
> >
> >
> > Maybe this is already possible… Whether it's useful, I don't know.
> >
> >
> 
> 
> -- 
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
> 
> The disease DOES progress.  MANY people have died from it.  And
> ANYBODY can get it.
> 
> Denmark: free Karina Hansen NOW.