| This is what I learned from designing data architectures: If your data is variegated in format and form, don't look for a single tool/method solution to organize them. There is no single all-purpose organization method. Don't start with figuring out a method to organize your information. You will end up overengineering your org method. Instead, organize your information per "use-case". Start with a specific use-case/project (e.g. writing a blog or paper), and work backwards to figure out how to organize your data to meet the requirements of that project. Do a couple of iterations. After a couple of projects, and you will naturally discover your own data use patterns. If you go with a super organization system on day 1, it will likely be too general and require too much effort (tagging, keywords, hierarchies, version controlled, branches, etc.) you will end up expending resources on metadata management on data that you may never ever need to retrieve and very soon you will abandon the effort. My PKM system is very simple: a single unorganized Google Docs for quick thoughts and ideas (just bullet points), separate Google Docs files for specific projects, etc. and Dropbox for files. It's simple, searchable, and multi-device. I also occasionally use some specialized tools like Jabref (BibTeX) for specific types of data like references, but I hardly ever write papers anymore, so these have fallen by the wayside. I've tried wikis but due to their multipage nature, they segment knowledge too finely (often there are wiki pages hidden in deep in the link hierarchy that I forgot existed). Wikis don't fit the PKM use case that well, so these too have fallen by the wayside for me. For me, PKMs need to in some way feel like a single broadsheet where I can easily see and touch my information without having to drill-down hierarchies and follow too many links. p.s. I've heard good things about Evernote. It's a little too heavy for me, but many people seem to find it useful. |
I think this is an important point. I like to start with a few simple rules:
- To retrieve information, I should know where to start: a Schelling point.[0] For me, this is the home page of my wiki. For wenc, it's a Google Doc.
- It shouldn't take me more than three clicks to get from my starting point to the information I'm looking for.
- Links/URLs will tie everything together. They are the edges in my knowledge graph. But as wenc notes, keep the graph shallow.
Then I need to be rigorous, reorganizing things when they don't work intuitively and adding new nodes when something I need has not yet been recorded. As wenc puts it, "discover your own data use patterns."
Wikis do work for me, provided it's organized around Schelling points. I've used and refined these principles in setting up wikis at my last 3 companies and it's worked pretty well for organizing a collective knowledge base as well.
[0] https://en.wikipedia.org/wiki/Focal_point_(game_theory)