Hello,
being quiet new with LogSeq i would like to ask how some of you document meetings?
- Hierarchy — Do you use hierarchies in projects to organize information in meetings?
- Daily Agenda (Journal) — Do you document meetings here and tag them so they will show up in another page as linked items?
- In dedicated project pages — and then link to these from the respective journal?
Is there a best practice?
Best Regards
Oliver
1 Like
Short answer: All of your points have their place.
Long answer: There is no established best practice, neither among note-keeping applications, nor within Logseq’s community. Learn from others, but develop your own approach. Below is my own take on it.
- Hierarchies are for strictly hierarchical things, not for organization.
- Most relationships are not hierarchical.
- Their structure should emerge within the graph.
- For local hierarchy needs, use the normal indentation of the outliner.
- This covers the majority of the cases.
- Don’t put your pages into fixed hierarchies, unless some pages are really subpages.
- Even in such cases, consider merging the subpages into their parent.
- Projects are hierarchical as long as they can be broken into subprojects.
- Meetings generally don’t participate in hierarchies themselves.
- The outline of a meeting is perfectly served by indentation.
- This is essentially your point 1.
- Daily Agenda is for keeping together same-day events.
- Almost everything begins there, because almost everything takes place in time.
- For some applications, it is ok for their notes to remain in journal forever.
- This is useful only when the notes are consistently tagged.
- Otherwise it is a mere calendar.
- This is essentially your point 2.
- For serious knowledge management, most notes should be moved to dedicated pages.
- This should happen when ready, i.e. confident enough about the destination.
- Projects totally deserve dedicated pages (sometimes even graphs).
- Journal should still keep track of their events, by referencing the respective project.
- This is essentially your point 3.
- Meetings take place in time, so they are excellent candidates for journal.
- If a meeting needs complicated organization, it deserves its own page.
- Journal should still keep a reference to the dedicated page.
5 Likes
Wow, thank you very much, that‘s a great answer and brings me really forward. I can very much attach to it and will start more in the Daily Journal, from there organizing my notes further. I already made some steps with queries to show information in dedicated pages. Eager to learn more.
Thanks a lot.
Can you provide a specific example of this? I’m not quite sure if I understand. What is fixed hierarchy?
Hi @Daliboroslav ,
from my understanding what @mentaloid mean with „fixed hierarchy“ is not to lock notes into hierarchies as one would then loose the concept of a multidimensional graph because the hierarchy gets more „weight“ in your information system than the „loose coupling through the graph“.
Trying an example Apple/Steve Jobs, Apple/Tim Cook will lock them as (former) emplyees of Apple but there‘s more like their role as CEO, and other contexts you would have them in like a performer of a keynote or Steves relation to Steve Wozniak would all be with less weight.
1 Like
The typical example is that of book/chapter/page:
- Conceptually, a book is:
- the container of its chapters
- but a single entity
- So much, that some chapters have no titles, just numbers.
- A bad but understandable choice.
- A chapter is a sub-book, i.e.:
- A book can exist without a specific chapter:
- Multiple revisions of the same book may have different chapters.
- With different Table of Contents.
- A chapter cannot exist outside a book:
- All the revisions of the same chapter belong to the same book.
- It is always “chapter c (part) of book b”.
- If you can manage the whole book into a single Logseq page (properly indented), go for it.
- If you cannot, put the respective Logseq pages in a fixed hierarchy, which:
- is:
- about how things are
- There is always a fixed part:
- Each thing has a single concrete definition.
- Each division (e.g. chapter) is part of a single whole thing (e.g. book).
- not about how we look at things
- Different perspectives generate various abstract non-fixed hierarchies.
- Each thing may appear in multiple flexible queries.
- Each whole thing (e.g. book) may be divided in multiple ways (e.g. chapters).
- essentially follows the Table of Contents
- not the pages, but the chapters
- The pages of a book have nothing to do with the pages of Logseq.
2 Likes