[FR]: Source definitions from note properties

[FeralFlora]

Very interesting plugin! I think it would be very nice if you could source definitions directly from notes and their properties. For example, concept notes already present in my vault. This would be more straightforward as a user, imo.

My concrete suggestion, compared to the current system, is:

• Word -> Note file name (optionally (title property))
• Alias -> aliases property
• Definition -> definition property

This could be an optional behavior, as an alternative to the current single definition file approach.

Under this approach, a list of definitions would be created based on all notes with the definition property, or alternatively those with a specific tag, such as #concept.

[dominiclet]

Hi @FeralFlora, thanks for the suggestion! I agree that the current approach might not be the most straightforward, so I do appreciate suggestions to make it more intuitive. If I understand you correctly, your suggestion is to use file properties to register definitions? In that case would that mean that only 1 definition can be registered per file?

Also, placing definitions in file properties was something I considered but ultimately decided against as I felt that definitions should make up part of a user's notes instead of being relegated to the metadata of a file. Nevertheless, I think it can still be considered as an optional feature. Is there a particular use case that you are thinking of?

[FeralFlora]

Hi @FeralFlora, thanks for the suggestion!

Hi, and thanks for the quick response.

I agree that the current approach might not be the most straightforward, so I do appreciate suggestions to make it more intuitive. If I understand you correctly, your suggestion is to use file properties to register definitions? In that case would that mean that only 1 definition can be registered per file?

Yes, that was my first thought, although my main concern was sourcing the data from separate notes. To this end, I thought the properties would allow for easy retrieval. That was my main concern with this particular suggestion.

Alternatives to properties

Also, placing definitions in file properties was something I considered but ultimately decided against as I felt that definitions should make up part of a user's notes instead of being relegated to the metadata of a file.

That's a good point. As is, I actually tend to have my definitions in callouts inside my concept notes:

> [!info]+ Definition
> 
> Concept X is bla bla bla.

Of course, there are alternatives like using Dataview inline fields, which (while also a form of metadata) are at least in the note.

Or, perhaps more interestingly, using a ^definition block ID to designate the definition text. This could open up the possibility of sourcing the definitions from various types of blocks, including callouts and plain paragraphs.

Or lastly, the definition could be the text under any "Definition" heading (I guess this should not be hard-coded, but a user setting, to allow for localization to the language of the user).

In all these scenarios, the "Word" as currently signified by file headings, would be sourced from the file name or a particular property, like a title property. And, as suggested before, the alias is sourced from the aliases property. But the definition itself could be any block with a ^definition blockID.

Examples

Block ID

For example, let's say we have a note called "Landslide", with the aliases property as follows:

File name: Landslide
---
aliases:
- Landslip
---

Landslides, also known as landslips, are several forms of mass wasting that may include a wide range of ground movements, such as rockfalls, mudflows, shallow or deep-seated slope failures and debris flows. ^definition

Heading

File name: Landslide
---
aliases:
- Landslip
---

## Definition

Landslides, also known as landslips, are several forms of mass wasting that may include a wide range of ground movements, such as rockfalls, mudflows, shallow or deep-seated slope failures and debris flows.

## Another heading

More text

Out of these options, I think the block ID method will probably be easier to parse, but I am not sure.

Is there a particular use case that you are thinking of?

Nothing in particular, beyond making uptake easier. Of course, an alternative to my suggestion is to go the other way and construct a definition file, as currently required, programatically based on the data across the notes in the vault. This could, for example, be done using a Dataviewjs codeblock, if the Note Definition plugin was able to read the output of that.

[27escape]

I would like to see a more standard format for the definitions, https://www.markdownguide.org/extended-syntax/ has

First Term : This is the definition of the first term.

Second Term : This is one definition of the second term. : This is another definition of the second term.

Also I have seen the following style of definitions

*[term]: definition of term it would be possible to extend that to include the alias be separating the term with a pipe symbol '|' e.g.

*[term | alias]: definition of term

one final style would be

term: definition

I much prefer these more compact forms, though they do not give multiline definitions which can be useful in some cases

Many thanks for creating this plugin, whatever the form of the definitions, it will be useful!

[dominiclet]

@FeralFlora I'm not sure I agree with having one definition registered per file, it seems a little too restrictive in my opinion. However, I think reading and registering definitions from definitions embedded within notes is a fantastic idea. In particular, I think using callouts, similar to the example you gave, would be perfect for the following reasons:

1. It keeps the definition "out of the way" from the rest of the note
2. We have the added benefit of using Obsidian's formatting for callouts
3. It probably fits better with the workflow of most people since it does not require the user to maintain separate definition files

What do you think?

[dominiclet]

@27escape Thanks for the suggestion! I think a compact form of registering definitions is definitely useful, especially for quickly jotting down definitions. Nevertheless, as you've pointed out, there is a trade-off between efficiency and expressiveness, and this would likely boil down to personal preference. As such, I think including an option to enable compact definitions, perhaps by way of a file property, would be more appropriate here. What do you think?

[27escape]

@dominiclet I doubt that many people would have too many definition files, so one for compact and one for expressive would do it, if thats the direction you want to travel. @FeralFlora I like having all the definitions in one place, having them inline may lead me to repeat the creation of them in each file that references them, unless they have all been indexed the way they are now.

[FeralFlora]

I'm not sure I agree with having one definition registered per file, it seems a little too restrictive in my opinion.

That's alright, I wasn't really invested in the principle of strictly one definition per file, necessarily. It's just that sourcing the word name and alias from the note file name and aliases property seemed most intuitive, and least involved, to me, when going from a single file with definitions to definitions sourced from notes across the vault.

Another thing that motivated my initial suggestion is the principle of atomicity, common in Zettelkasten and knowledge management workflows, or the value of having narrowly-focused notes that concern one concept, idea or argument per note. See: https://notes.andymatuschak.org/zNUaiGAXp21eorsER1Jm9yU

This allows for interlinking, it allows you to see what concepts you've already written about, and to build upon them, rather than creating disjointed / duplicated notes, and to compare concepts, arguments and ideas, and it allows you to boil a concept down to its essentials, its definition, if you will.

So I thought my suggestion would fit well into this type of knowledge management workflow.

(Of course, other less atomic note types are then where the magic happens, by synthesizing knowledge from the atomic concept-oriented notes.)

---

What do you think?

I like that idea, and I think its doable.

But can you say a bit more about the syntax for title, alias, definition in this scenario?

[dominiclet]

@FeralFlora that's interesting, I see where you're coming from. I guess this would be fitting for someone with narrowly focused notes and I see how it would be helpful. Perhaps I'll consider implementing this in the future!

As for defining words inline via callouts I was thinking of using a custom "definition" callout, where the title is the word to be defined, followed by an optional "aliases" section, then the rest of the text as the definition, something like that:

> [!definition] Word
> Aliases: Word1, Word2
> 
> This is the definition for "Word".

[rolandhesz]

Hi @FeralFlora, thanks for the suggestion! I agree that the current approach might not be the most straightforward, so I do appreciate suggestions to make it more intuitive. If I understand you correctly, your suggestion is to use file properties to register definitions? In that case would that mean that only 1 definition can be registered per file?

Also, placing definitions in file properties was something I considered but ultimately decided against as I felt that definitions should make up part of a user's notes instead of being relegated to the metadata of a file. Nevertheless, I think it can still be considered as an optional feature. Is there a particular use case that you are thinking of?

I was tinkering with it, and ended up with a version that was looking at both the frontmatter properties and the original structure you defined.

I was thinking of 3 main ways to structure the definition:

1. Using your structure - heading is the word, next line in italics the alias(es), then the definition. (Btw. it seems to pick up every header level as the word), separated by ---. One file can have multiple words.
2. Using frontmatter properties: word, alias, definition. One file can have one word, although a slightly dodgy solution is to treat the frontmatter properties as arrays, and match them by index. Can lead to problems, especially when it comes to descriptions if you make a mistake while editing the content, indexes not matching, more element in one array than in the other, etc.
3. Don't use frontmatter but use properties in the body of the note, and use --- as separator.

   word:: confusion
   alias:: anarchy, bedlam, chaos, commotion
   definition:: "a situation in which people do not understand what is happening, what they should do or who someone or something is."
   ---

The last version allows you to add as many words in one note as you want. It also provides an easy way to extend the content, or even allow for some variation.

word:: confusion
synonyms:: anarchy, bedlam, chaos, commotion
category:: noun
meaning:: "a situation in which people do not understand what is happening, what they should do or who someone or something is."
---

And then it either just displays everything with no real rules

confusion

synonyms: anarchy, bedlam, chaos, commotion category: noun meaning: a situation in which people do not understand what is happening, what they should do or who someone or something is.

or you let the user define the properties they want to use and some basic formatting - bold, italic, underscored, quote text, maybe colour. Granted the last bit would require a UI and more work.

If you combine this with the callout idea, then you can have definitions where the actual definition text is very long, but not all of that appears in the hover text, only what is included in the callout.

[dominiclet]

Great suggestion, I do like that the third method you mentioned would enable the user to define properties they want to use. I think this would be good when we need a more expressive way of registering definitions, especially when more features are introduced.

[pkej]

@FeralFlora: https://github.com/dominiclet/obsidian-note-definitions/issues/1#issuecomment-2139163799

This allows for interlinking, it allows you to see what concepts you've already written about, and to build upon them, rather than creating disjointed / duplicated notes, and to compare concepts, arguments and ideas, and it allows you to boil a concept down to its essentials, its definition, if you will.

![[Ω/Definitions/Subtitling#Teksting for døve og hørselshemmede|TDHH]]

Using the default Obsidian linking works well for this, both for creating a "definition in-line" and for linking to a term specifically?

That said, I agree that allowing atomic files, in addition to dictionary files as today, for each definitions is useful as it gives more flexibility and combined with both file properties and/or inline properties it would work well for using MOCs, Zettelkasten, atomic writing. The current way works well for me, but I could easily like doing it atomically.