Noting Meetings


being quiet new with LogSeq i would like to ask how some of you document meetings?

  1. Hierarchy — Do you use hierarchies in projects to organize information in meetings?
  2. Daily Agenda (Journal) — Do you document meetings here and tag them so they will show up in another page as linked items?
  3. In dedicated project pages — and then link to these from the respective journal?

Is there a best practice?

Best Regards

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.

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.
1 Like