From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Hendy Subject: Re: org-mode for knowledge management Date: Mon, 13 Oct 2014 21:14:38 -0500 Message-ID: References: <87oatkkdes.fsf@wmi.amu.edu.pl> <87siiwc4gd.wl-n142857@gmail.com> <87oatihm88.wl-n142857@gmail.com> <87k345hgo9.wl-n142857@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdrdL-0005UP-Cj for emacs-orgmode@gnu.org; Mon, 13 Oct 2014 22:14:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdrdJ-0003p7-OT for emacs-orgmode@gnu.org; Mon, 13 Oct 2014 22:14:43 -0400 Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:63221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdrdJ-0003p1-AV for emacs-orgmode@gnu.org; Mon, 13 Oct 2014 22:14:41 -0400 Received: by mail-lb0-f170.google.com with SMTP id u10so7432899lbd.15 for ; Mon, 13 Oct 2014 19:14:39 -0700 (PDT) In-Reply-To: <87k345hgo9.wl-n142857@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Daniel Clemente Cc: emacs-orgmode , Marcin Borkowski On Sun, Oct 12, 2014 at 2:48 AM, Daniel Clemente wrote: > >> [=E2=80=A6] >> 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 a= n 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 obv= ious for you, you cannot change topic, =E2=80=A6 Whereas in notes, you're f= ree. 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. > > =E2=80=A6 However, I don't consider that rewriting (specific=E2=86=92ge= neral) 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.: =E2=80=9Esee what I did in this case ([[link_to_the_report]])=E2=80= =9C.). 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 repo= rts 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 =E2=80=9E= code style guide=E2=80=9C because I did it already in project X, so I add k= nowledge 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 note= s (another file, project-unrelated). >> > Of course copy+paste is a nightmare to maintain (see: DRY). I am sti= ll forced to do it with some org tables which do complex calculations. I th= ink org offers dynamic tables to apply the same process to different data s= ources, but it gets complex. I think there's no such thing as =E2=80=9Etemp= lates=E2=80=9C where you change the base one and all uses of it (in all fil= es) are automatically updated. >> > >> > About links: in org-mode they all look the same, but semantically th= ere are many types, like: >> > - *is-a*: =E2=80=9Ethis is a concrete implementation of [[that generic= knowledge]]=E2=80=9C >> > - *related*: =E2=80=9Erelated to this is: [[that]]=E2=80=9C >> > - *same-as*: =E2=80=9Ethis and [[that]] are exactly the same topic, so= write only under that header, not here=E2=80=9C =E2=86=90 this is poor man= 's transclusion, or more like =E2=80=9Esymbolic links=E2=80=9C in ext4. Wit= h it, a header seems to be present in many places at the same time; in real= ity 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 reade= r; but in your notes, you know already which links will you need in the fut= ure). > - In my example, the link meant =E2=80=9Ethis is the same as that=E2=80= =9C, and I think this is always a basic concept, even in complex scenarios.= In your case, your link may mean something different (like: =E2=80=9Ethis = heading is a specific wording of that knowledge=E2=80=9C) > - That header with empty contents that says =E2=80=9Efor this, don't look= here but look there: [[there]]=E2=80=9C is only one line and doesn't get i= n 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 n= ext 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