Loading request...
A user suggests creating a knowledge graph that focuses on connections rather than a traditional folder structure for organizational wikis, to improve information retrieval.
\_\_**This is a pretty long article and this is a very short excerpt so please read the full article if you want to find out more**\_\_ How is it that I can find where the third King of the Belgians was born in a few clicks yet finding out what our expense policy is about is something you would rather ask a colleague, then look for on the organisational wiki? I’ve done a lot of research about this over the years, and I would like to share my ideas on how to set up a documentation store. This is going to be a two part post. The first one is the general outline and philosophy. The second part is about structuring project governance documentation. \## The knowledge graph A lot of organisational wikis are stored in folder structures, This mimics a file system and in the case of SharePoint is also often just a copy and paste from one. A bit of a dumping ground where you work from a file folder and try not to go out of it. Everything is trapped in its own container. The idea of a knowledge graph goes in the opposite direction. In its rawest form, you do away with folders and structure altogether. You create an interlinked setup that focuses more on connections than strucute. The beautiful concept behind Knowledge Graphs is that they create organic links with relevant information without the need for you to set it up. \## The MOC: The Map of Content These are landing pages that help you on your way. To go to a topic you go to one of the main ideas of the topic, and it will guide you there. These pages can also include information themselves to introduce you towards the bigger concept. A MOC of Belgium would not direct you to a Belgium detail page, it would serve as both the main topic and the launch pad towards the deeper topics. \## Atomic Documentation The issue with long articles is that not a lot of people find the motivation to write them. It takes a lot of work to write a decent long explanation of a concept. It’s also a bit daunting to jump into a very long article and read the entire thing when you are actually just in need for a small part of the information. This is where Atomic Documentation comes in: one concept per page. Reference the rest. \## Organized chaos Leaving a dumping ground with MOCs and notes is too intimidating for new users to drop into. You’re never going to get that adopted. You’re going to need folders. \- Projects \- Applications \- Processes \- Resources \- Archive \## Living documentation We use small and easily scannable documents to quickly communicate one piece of information. Once we are dragging in different concepts we link, or create new small pieces of information. And encourage people to do deep dives if the time (and interest) allows it. If not, people still have a high level overview of what they need. Stay tuned for the next part in two weeks where we dive into project documentation.