* org-mode for knowledge management
@ 2014-10-09 22:17 Louis
2014-10-09 23:54 ` Marcin Borkowski
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Louis @ 2014-10-09 22:17 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: org-mode for knowledge management 2014-10-09 22:17 org-mode for knowledge management Louis @ 2014-10-09 23:54 ` Marcin Borkowski 2014-10-10 15:46 ` Daniel Clemente 2014-10-10 0:18 ` Thomas S. Dye 2014-10-13 13:11 ` Brett Viren 2 siblings, 1 reply; 25+ messages in thread From: Marcin Borkowski @ 2014-10-09 23:54 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-09 23:54 ` Marcin Borkowski @ 2014-10-10 15:46 ` Daniel Clemente 2014-10-10 21:40 ` mbork 2014-10-10 21:48 ` John Hendy 0 siblings, 2 replies; 25+ messages in thread From: Daniel Clemente @ 2014-10-10 15:46 UTC (permalink / raw) To: Marcin Borkowski; +Cc: emacs-orgmode > > > > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-10 15:46 ` Daniel Clemente @ 2014-10-10 21:40 ` mbork 2014-10-10 21:48 ` John Hendy 1 sibling, 0 replies; 25+ messages in thread From: mbork @ 2014-10-10 21:40 UTC (permalink / raw) To: emacs-orgmode 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! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-10 15:46 ` Daniel Clemente 2014-10-10 21:40 ` mbork @ 2014-10-10 21:48 ` John Hendy 2014-10-11 2:53 ` Eric Abrahamsen 2014-10-11 11:36 ` Daniel Clemente 1 sibling, 2 replies; 25+ messages in thread From: John Hendy @ 2014-10-10 21:48 UTC (permalink / raw) To: Daniel Clemente; +Cc: emacs-orgmode, Marcin Borkowski 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] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-10 21:48 ` John Hendy @ 2014-10-11 2:53 ` Eric Abrahamsen 2014-10-12 4:54 ` John Hendy 2014-10-11 11:36 ` Daniel Clemente 1 sibling, 1 reply; 25+ messages in thread From: Eric Abrahamsen @ 2014-10-11 2:53 UTC (permalink / raw) To: emacs-orgmode 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] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-11 2:53 ` Eric Abrahamsen @ 2014-10-12 4:54 ` John Hendy 2014-10-13 2:42 ` Eric Abrahamsen 0 siblings, 1 reply; 25+ messages in thread From: John Hendy @ 2014-10-12 4:54 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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] > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-12 4:54 ` John Hendy @ 2014-10-13 2:42 ` Eric Abrahamsen 2014-10-13 3:15 ` Daniel Clemente 0 siblings, 1 reply; 25+ messages in thread From: Eric Abrahamsen @ 2014-10-13 2:42 UTC (permalink / raw) To: emacs-orgmode 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] >> >> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-13 2:42 ` Eric Abrahamsen @ 2014-10-13 3:15 ` Daniel Clemente 2014-10-13 5:17 ` Samuel Wales 2014-10-14 1:14 ` Eric Abrahamsen 0 siblings, 2 replies; 25+ messages in thread From: Daniel Clemente @ 2014-10-13 3:15 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-13 3:15 ` Daniel Clemente @ 2014-10-13 5:17 ` Samuel Wales 2014-10-14 3:47 ` Daniel Clemente 2014-10-14 1:14 ` Eric Abrahamsen 1 sibling, 1 reply; 25+ messages in thread From: Samuel Wales @ 2014-10-13 5:17 UTC (permalink / raw) To: Daniel Clemente; +Cc: Eric Abrahamsen, emacs-orgmode (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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-13 5:17 ` Samuel Wales @ 2014-10-14 3:47 ` Daniel Clemente 0 siblings, 0 replies; 25+ messages in thread From: Daniel Clemente @ 2014-10-14 3:47 UTC (permalink / raw) To: Samuel Wales; +Cc: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-13 3:15 ` Daniel Clemente 2014-10-13 5:17 ` Samuel Wales @ 2014-10-14 1:14 ` Eric Abrahamsen 1 sibling, 0 replies; 25+ messages in thread From: Eric Abrahamsen @ 2014-10-14 1:14 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-10 21:48 ` John Hendy 2014-10-11 2:53 ` Eric Abrahamsen @ 2014-10-11 11:36 ` Daniel Clemente 2014-10-11 19:45 ` Brady Trainor 2014-10-12 5:03 ` John Hendy 1 sibling, 2 replies; 25+ messages in thread From: Daniel Clemente @ 2014-10-11 11:36 UTC (permalink / raw) To: John Hendy; +Cc: emacs-orgmode, Marcin Borkowski 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-11 11:36 ` Daniel Clemente @ 2014-10-11 19:45 ` Brady Trainor 2014-10-12 4:29 ` Daniel Clemente 2014-10-12 5:03 ` John Hendy 1 sibling, 1 reply; 25+ messages in thread From: Brady Trainor @ 2014-10-11 19:45 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-11 19:45 ` Brady Trainor @ 2014-10-12 4:29 ` Daniel Clemente 0 siblings, 0 replies; 25+ messages in thread From: Daniel Clemente @ 2014-10-12 4:29 UTC (permalink / raw) To: Brady Trainor; +Cc: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-11 11:36 ` Daniel Clemente 2014-10-11 19:45 ` Brady Trainor @ 2014-10-12 5:03 ` John Hendy 2014-10-12 7:48 ` Daniel Clemente 1 sibling, 1 reply; 25+ messages in thread From: John Hendy @ 2014-10-12 5:03 UTC (permalink / raw) To: Daniel Clemente; +Cc: emacs-orgmode, Marcin Borkowski 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-12 5:03 ` John Hendy @ 2014-10-12 7:48 ` Daniel Clemente 2014-10-14 2:14 ` John Hendy 0 siblings, 1 reply; 25+ messages in thread From: Daniel Clemente @ 2014-10-12 7:48 UTC (permalink / raw) To: John Hendy; +Cc: emacs-orgmode, Marcin Borkowski > […] > 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). ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-12 7:48 ` Daniel Clemente @ 2014-10-14 2:14 ` John Hendy 0 siblings, 0 replies; 25+ messages in thread From: John Hendy @ 2014-10-14 2:14 UTC (permalink / raw) To: Daniel Clemente; +Cc: emacs-orgmode, Marcin Borkowski 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-09 22:17 org-mode for knowledge management Louis 2014-10-09 23:54 ` Marcin Borkowski @ 2014-10-10 0:18 ` Thomas S. Dye 2014-10-10 2:32 ` Louis ` (2 more replies) 2014-10-13 13:11 ` Brett Viren 2 siblings, 3 replies; 25+ messages in thread From: Thomas S. Dye @ 2014-10-10 0:18 UTC (permalink / raw) To: Louis; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-10 0:18 ` Thomas S. Dye @ 2014-10-10 2:32 ` Louis 2014-10-10 2:34 ` Louis 2014-10-13 19:29 ` Louis 2 siblings, 0 replies; 25+ messages in thread From: Louis @ 2014-10-10 2:32 UTC (permalink / raw) Cc: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-10 0:18 ` Thomas S. Dye 2014-10-10 2:32 ` Louis @ 2014-10-10 2:34 ` Louis 2014-10-13 19:29 ` Louis 2 siblings, 0 replies; 25+ messages in thread From: Louis @ 2014-10-10 2:34 UTC (permalink / raw) To: Thomas S. Dye; +Cc: Louis, emacs-orgmode 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-10 0:18 ` Thomas S. Dye 2014-10-10 2:32 ` Louis 2014-10-10 2:34 ` Louis @ 2014-10-13 19:29 ` Louis 2014-10-13 19:36 ` Thomas S. Dye 2 siblings, 1 reply; 25+ messages in thread From: Louis @ 2014-10-13 19:29 UTC (permalink / raw) To: Thomas S. Dye; +Cc: Louis, emacs-orgmode 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 > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-13 19:29 ` Louis @ 2014-10-13 19:36 ` Thomas S. Dye 2014-10-13 23:10 ` Louis 0 siblings, 1 reply; 25+ messages in thread From: Thomas S. Dye @ 2014-10-13 19:36 UTC (permalink / raw) To: Louis; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-13 19:36 ` Thomas S. Dye @ 2014-10-13 23:10 ` Louis 0 siblings, 0 replies; 25+ messages in thread From: Louis @ 2014-10-13 23:10 UTC (permalink / raw) To: emacs-orgmode 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 > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: org-mode for knowledge management 2014-10-09 22:17 org-mode for knowledge management Louis 2014-10-09 23:54 ` Marcin Borkowski 2014-10-10 0:18 ` Thomas S. Dye @ 2014-10-13 13:11 ` Brett Viren 2 siblings, 0 replies; 25+ messages in thread From: Brett Viren @ 2014-10-13 13:11 UTC (permalink / raw) To: Louis; +Cc: emacs-orgmode [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2014-10-14 3:47 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-09 22:17 org-mode for knowledge management Louis 2014-10-09 23:54 ` Marcin Borkowski 2014-10-10 15:46 ` Daniel Clemente 2014-10-10 21:40 ` mbork 2014-10-10 21:48 ` John Hendy 2014-10-11 2:53 ` Eric Abrahamsen 2014-10-12 4:54 ` John Hendy 2014-10-13 2:42 ` Eric Abrahamsen 2014-10-13 3:15 ` Daniel Clemente 2014-10-13 5:17 ` Samuel Wales 2014-10-14 3:47 ` Daniel Clemente 2014-10-14 1:14 ` Eric Abrahamsen 2014-10-11 11:36 ` Daniel Clemente 2014-10-11 19:45 ` Brady Trainor 2014-10-12 4:29 ` Daniel Clemente 2014-10-12 5:03 ` John Hendy 2014-10-12 7:48 ` Daniel Clemente 2014-10-14 2:14 ` John Hendy 2014-10-10 0:18 ` Thomas S. Dye 2014-10-10 2:32 ` Louis 2014-10-10 2:34 ` Louis 2014-10-13 19:29 ` Louis 2014-10-13 19:36 ` Thomas S. Dye 2014-10-13 23:10 ` Louis 2014-10-13 13:11 ` Brett Viren
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).