Zettelkasten Forum


reference management for project notes?

Ahrens book "How to take smart notes" describes a workflow for "project notes".

what are "project notes"

"project notes" are created outside of a Zettelkasten. They are stored in a project specific context, discarded or archived1 and used in a project specific environment.

reference system for project notes

References are managed in a project specific environment. It is a subset of reference collection of your Zettelkasten system, may contain additional references or replacements for specific references to fit in the goal of the project.

question

Is anyone keeping a separate reference collection for projects? What is the idea behind this? How much control do we need? I see no benefits for this. One thing that comes to mind is when the project is in a different language. Then each reference must be replaced with a source in the respective language.


  1. not to be confused with The Archive. I am referring to archiving in the sense of archivation. ↩︎

my first Zettel uid: 202008120915

Comments

  • No. As long it is knowledge, I keep it in my Zettelkasten. One of the main benefits of the Zettelkasten Method is to ignore project boundaries and always benefit from all of your knowledge work for every project.

    If you separate project notes and whatever other notes you are thinking on a more superficial level. Technically, I don't try to manage notes but to manage knowledge. It seems to be a play of words but it is not. The different concepts reflect the different levels of thinking about the issue: Notes are the means, knowledge is the end. So, the goal is not to do anything with notes but with knowledge.

    I am a Zettler

  • @zk_1000 said:
    Is anyone keeping a separate reference collection for projects? What is the idea behind this? How much control do we need? I see no benefits for this. One thing that comes to mind is when the project is in a different language. Then each reference must be replaced with a source in the respective language.

    Project Notes are just another form of structure—a Structure Note on a project rather than a book or article. The only difference I make is giving the note title's special signifiers, so I can easily distinguish them in the note list and the tag #project for "saved search" capabilities. 202011250546 ★ Jekyll Static Website

    @sfast said:
    Technically, I don't try to manage notes but to manage knowledge. It seems to be a play of words but it is not. The different concepts reflect the different levels of thinking about the issue: Notes are the means, knowledge is the end. So, the goal is not to do anything with notes but with knowledge.

    I stand and bow to the east. Sascha, this is helpful and something I what to pay more attention to. I spend way too much time futzing with note format and template format at the expense of "futzing" with knowledge. Too much focus on the means is not helping me reach the potential of the ends. It comes down to opportunity costs.

    Will Simpson
    I'm a zettelnant.
    Research areas: Attention Horizon, Productive Procrastination, Dzogchen, Non-fiction Creative Writing
    kestrelcreek.com

  • I second what @sfast said. The richness comes from finding connections where you don't expect them.

    For an anecdotal example, when I was working on a long forum post for my university classes (a common occurrence), my ZK searches brought me to a my notes on a short story. My program is not related to literature, but I nevertheless included something about the story in my notes. Turns out, a lot of people knew the story and the cross-pollination of disciplines for that project was very well-received.

    Observations logged here: write.as/via-poetica

  • edited December 2020

    @zk_1000 said:
    Ahrens book "How to take smart notes" describes a workflow for "project notes".

    what are "project notes"

    "project notes" are created outside of a Zettelkasten. They are stored in a project specific context, discarded or archived[^1] and used in a project specific environment.

    Is anyone keeping a separate reference collection for projects? What is the idea behind this? How much control do we need? I see no benefits for this. One thing that comes to mind is when the project is in a different language. Then each reference must be replaced with a source in the respective language.

    Hmmm...let me give you a perspective from the semi-retired stage of life.

    I have no issue with having separate project notes which contain information and ideas that are not in my ZK. For one, the system for doing so is set up and prescribed by the way the company for whom I work functions. They want project folders to exist, in a certain form and place. Everyone working for the company knows how to do that and how to access the information. And the information stored in those project folders is voluminous and, for me, largely unrelated to the main purposes for my ZK. So I chose not to include them in my ZK.

    I am a proponent of putting all of the ideas that are important to me in my ZK. But there are so many ideas that I deal with that are not important and/or useful to me, that there is no way I am going to waste time putting them into my ZK.

    So this is a very legitimate question that you ask, which requires careful thought. Perhaps someone who is young (I think of anyone under 40 as being young :wink: ) or someone who is focussed largely on one task (such as carrying out research for an M.Sc. or Ph.D. thesis) will want to keep most of their ideas in their ZK. That is because they want to use their ZK to help with the accumulation and processing of knowledge in their field of interest.

    But I can assure you that as time goes on, you will encounter an avalanche of ideas that are of little interest to you. It is not that they lack value or don't represent "real knowledge"; it is just that they lack value to you. As I have pointed out elsewhere, you will also start to think carefully about how you prioritize your time and one of those will be in how you use your ZK and thus what you put into it.

    To be ridiculous for the sake of making a point, if we all had unlimited time and energy, we could attempt to include all the world's knowledge in our ZK. Theoretically, it would be possible but practically speaking we would spend a huge amount of time and effort on activities of little value to us.

    I thus believe we need to be quite discerning about what goes into our ZK, and to do that, we need to be very clear about the purposes of our ZK, i.e., for what purposes are we going to use it? Now, in some instances, it might be difficult to decide whether a concept or idea should be included, i.e., whether it now does or at some time in the future will serve our purpose for creating and maintaining a ZK. In that case, don't dither or agonize, just include it. But I submit to you that there will be many cases where we can immediately see there will be no value in including an idea or concept in our ZK. We may still desire to access that information at some point or it may still be valuable for historical or legal purposes; in that case, store it in a "project file". That is one way that I use Bear.

    I submit to you that most of us already make this distinction between "ideas of interest or useful to me" and "ideas not of interest or useful to me", and we act accordingly in relation to our ZK. We do it almost unconsciously. So the real question is: how do your store, organize and later access information that doesn't belong in your ZK?

  • edited December 2020

    @GeoEng51 said:
    So the real question is: how do your store, organize and later access information that doesn't belong in your ZK?

    Ahren's answer to that question is to either archive it or delete it. To me, that makes completely sense.

    Unfortunately the author does not provide any insight into why he proposes a separate reference management. The concept is completely obscure to me :confused:

    Somehow i cannot associate project notes with knowledge work. Sometimes, Ahren's book is a bit confusing to read, the book lacks on overview for certain aspects to be comprehensible.

    The author makes it clear that, to make his concept work, it is important to separate projects from the slip-box. To me, a project contains no knowledge. Although it can be confusingly similar sometimes, the structure of a project is also different from the structure of knowledge.

    @GeoEng51 brings in another interesting perspective: to him a project contains no personal value as knowledge. I think we are on the same page, only explaining it differently.

    I acknowledge that many of us are working inside of a Zettelkasten, for writing a book, a project report, a task list, diary, etc. I don't understand what it means to have a project inside a Zettelkasten and tag it with #project. So, are we still talking about the same concepts or something different? I am managing knowledge AND i am managing notes. If you have a look at the Zettelkasten method, only The Archive contains knowledge. A project is the world i am building around it. Despite of that all of my projects i am currently working on still benefit from all of my knowledge work because i am treating both as a closed system.

    @Sociopoetic said:
    Turns out, a lot of people knew the story and the cross-pollination of disciplines for that project was very well-received.

    This is a very helpful advice. An anecdote is even better if the story is well-known. Thank you :blush:

    Post edited by zk_1000 on

    my first Zettel uid: 202008120915

  • @sfast you seem to work in another direction, "killing" the inbox and other elements.

    One of the main benefits of the Zettelkasten Method is to ignore project boundaries and always benefit from all of your knowledge work for every project.

    i am not sure if i am following this advice or not. I think i do. With knowledge work i know how to do the project, with the project i do the project.

    my first Zettel uid: 202008120915

  • edited December 2020

    @zk_1000 A P.S. to my comment, spurred by your recent post. As often happens on this forum, people have different meanings in their head for what ostensibly is common terminology. To actually communicate, everyone needs to agree on a common set of definitions. This isn't a criticism, just a statement of how things normally work between humans from different backgrounds and with different skill sets.

    For example, what is a "project"? To some, it is a very informal box that they draw around a loose assemblage of information that is somehow related, and which they want to keep associated. For others, it is a very formal distinction of associated information that is organized for a specific purpose, often to answer a question or accomplish a task (or both). If you used the first definition, I suppose you could have a project within your ZK, if that helped the way you accessed and thought about your information. If you used the second definition, which I was doing in my earlier comments, then a project might contain a lot of information you didn't want in your ZK and it wouldn't make sense to try to incorporate the entire project within your ZK.

    The other term I believe is used a bit loosely on the forum is "knowledge". By "loosely" I don't mean "incorrectly" but just "used in different ways by different people". Some people who work in the knowledge management field might feel they are the only ones who understand the term but clearly, it is going to mean different things to different people.

    Another example - in my world (engineering), I deal with:

    • Information (data and facts, usually about the world around me)
    • Specifications (how something should be built and how it should function)
    • Problems (basically, a definition of something that isn't working the way I expect or want it to)
    • Ideas (associations and relationships between bits of information, models of how the world around us "works", possible solutions to problems)
    • Consequences (what might happen if what I build doesn't function properly or outright fails)
    • Risks (a combination of consequences and probability of occurrence)

    and probably a few others that I could list if I spent more time thinking about it.

    How much of that is "knowledge"? I would argue that with the exception of the first bullet, most of it is knowledge. Why? Because an engineer can't just dish it out well cooked and tasty, fresh out of school. He or she needs to gain experience, under the guidance of a mentor, over time. They first learn, then they seek to understand and finally they integrate what they understand into something they call knowledge. And then after they have had a few successes and more importantly failures, they might start to develop judgement and wisdom. Some of that would be quite worthy of inclusion in a ZK.

    Obviously, I use all these terms from my own perspective.

    I have started to build some of the above knowledge into my ZK - not because I want to capture the way I think and operate as an engineer (that could be a purpose for a ZK, but it's not for me right now), but because the concepts that I am introducing into my ZK have some application to how I live my life and why and how I make decisions, which is what I want to communicate to my children and grandchildren.

    Haha! I went far afield from your original question. Oops!

Sign In or Register to comment.