Re: org-mode for knowledge management

[John Hendy <jw.hendy@gmail.com>]

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