Efficient way to create a glossary of terms?

Questions & Help
1

I have a list of terms I’m extracting from a text book. I want to store these terms so that I can:

A) hover over them and see their definitions
B) see term relationships on the graph
C) create flash cards I can use to study
D) categorize terms based on domains

I want to avoid duplication of text, but I’m not sure what a good structure is. A page per glossary item containing a card and its definition? Tag on the page propertoes to organize by domain? But then also on the card?

I also want to avoid a huge “glossary” node on the graph with all the terms connected.

Thoughts?

2

Welcome.

  • Yes.
  • Logseq pages should better be concepts.
    • If a concept involves more than one term, put all of them (and their flashcards) in the same page.
  • If needed, yes. But not sure what you mean.
  • Put the duplicated text in a single block, then link to it from different places.
4

I am also interested in this question, my problem is that I am trying to use Logseq to create my company documentation, a term sometimes deserves a page on our graph, but sometimes a term is “too small”. For instance, the term scrum would be better served as a single block in the glossary of terms, and have it referenced every time it is mentioned, as a block. The block will have a very brief definition of it and external links to the scrum guide, then the reader can get and small definition hovering and an external link to know more if he likes.
On the other hand, the term “project” has a strong and specific definition within our organization; thus it deserves its page, there the reader will get the definition, and a list of our current projects and other artifacts to manage projects in our company.
The glossary of terms will have the term scrum not linked, and the term project linked in the graph, referencing to external and internal resources. Only ‘project’ will have a representation on our graph.
If somehow a term “grows”, then the page should be created and appropriately referenced in the glossary of terms, allowing us to change our mind and create queries to list those terms. If appropriate metadata is set on either page or blocks.
The problem I am trying to solve is to declutter the graph when too many pages have been created, using a Glossary of terms to “hold terms” until there is a need to expand its definition internally.

Addendum:
The con of using terms as blocks and not pages is that those won’t appear on slash command. You will need a quick a list of terms somewhere. However, having a controlled vocabulary on a shared logseq graph makes sens to me from the data governance standpoint.

5
  • Quantity is a wrong criterion.
    • It should not be relevant.
  • If a term is:
    • an actual concept within the company (i.e. the graph), it should have a page in it
      • even an empty page
      • If it should appear on slash command, it is an actual concept.
    • a note on a concept, it should be a block
      • even a big block with a whole hierarchy of child-blocks
1 Like
6

Agree. Thanks for the acute summary.