Obsidian Properties: Best Practices and Why?

Knowledge management
21

I have different file “types” for different uses, and for that reason the set of properties varies by use (structure must be earned, right?). I use templates for each type that automatically populate creation date (for the reasons AlanG mentioned), template used (makes it easy to search and filter) and version (I fiddle with vault structure — up to v4.1 so far). Some plugins require specific properties, so those are built into specific templates. On most files, I include a status field.

Once upon a time I used an excessive amount of fields in frontmatter but experience taught me that many were never actually used, so I’ve limited myself to no more than a half-dozen in any template.

This really rings true:

What makes me a passionate Obsidian user is that the application isn’t strictly teleological. I still use it for several different purposes that the term “note-taking” fails to convey completely. The danger, as the OP said, is becoming a metadata janitor.

4 Likes
22

Reading through this thread, the one property that most seem to agree is important is type.

And I guess the note’s type would determine which other properties the note would have, beyond a few basic ones, such as ‘created’ which apply to the note itself.

3 Likes
23

Question about weight tracking: Do you have a weight property on each daily note?

I have been doing this with an inline Dataview property (Weight::), but I feel like I clutter my daily notes and have been considering changing these to properties.

1 Like
24

I have a weight property in the YAML for days that I’ve weighed myself, so it’s only included when there is an associated weight.

1 Like
25

I agree that “type” is pretty central and dictates the other properties. For me, another central property is “summary.”

Whether its a memo, permanent, meeting, project, or book note, I do my best to summarize what I’m doing with the note. Coupled with a single “link” to a MoC, pulling these summaries into Dataview tables or lists is helpful to get a lay of the land.

5 Likes
26

Why is created date important? What do you use the created date for?

27

…to know when I wrote a note… :grimacing:

6 Likes
28

I have now for almost 10 years of notes in my vault. The property Created is very useful to create a history table from all the notes and see in what order some notes were created. What idea let to another. It is another type of linking between notes that can only be seen by filtering by time.

An important thing, which is also mentioned above by @AlanG, is that you should use your own property Created and not rely on the default meta data. Copying your notes between devices or software can lead to a reset of the meta data.

10 Likes
29

Are there best practices for namespacing the properties? Sorry if I missed any such discussion?

Example of a namespace: properties for one plugin.

Another example from @muted:

type: event
event:
 location: [12345, 12345]
 type: birthday
 date: 2023-06-14T22:00:00.000Z
 state: passed

Is it possible to have this event namespace with Obsidian Properties? I don’t see it.

30

nested properties aren’t currently suppoted

31

Treat each obsidian file as an object and use the principles of object-oriented programming to assign properties.

4 Likes
32

The object-oriented method doesn’t work for my commonplace notes.

Is this class note a field, area, definition, a problem, or a statement? Does this conference note belong to the talk type or the topic type? The answer is ambiguous.

The OOP solution to this problem is interfaces, but frankly that’s too much janitorial work.

I enforce just one property to all commonplace notes: the parents type. This turns the entire commonplace book into a directed acyclic graph – since I’m careful not to create cycles – which enforces a loose yet flexible hierarchy.

Notes that are outside of the commonplace book are more likely to belong in their own siloed collections, such as the literature, daily, media, and bookmark types. For those I enforce a more OOP-style schema. e.g.

tags: 
 - literature
bibtex: "bibtex string"
aliases: ["citekey"]
url: "https://url-for-sharing-paper-with-coworkers"
file: [[filename.pdf]]
processed: true
parents: [ [[relevant-topic-1]], [[relevant-topic-2]] ]
33

I hope this conversation continues! I really love the idea of properties but like many others have said, have scaled back its use to just aliases. I use hashtags because they seem much more natural to me.

I’ve thought about using properties as part of an auto-classification system where every file gets assigned a few properties via openai:

  • type (i.e. article, summary, list, meeting-note, quote, etc.)
  • topic (i.e. business, parenting, etc.)
  • summary
  • similar

The goal would be to make each file more findable and better linked. The downside is that it’d just create a lot of noise within the files and I’m not sure if it’d really pay off.

1 Like
34

You will need to use different syntax from now on:

From Properties Help:

Internal links in Text and List type properties must be surrounded with quotes. Obsidian will automatically add these if you manually enter internal links into properties, but be careful to add them when using templating plugins.

---
link: "[[Link]]" 
linklist: 
  - "[[Link]]" 
  - "[[Link2]]"
---
2 Likes
35

It depends on the note. For most of my notes, I use nothing more than aliases and possibly tags. (I’m more likely to use hashtags, though - I put them at the bottom of the note.)

When I store a date, source, etc. I typically keep these as part of the structured body of the note.

For book notes or for recipes I have more extensive header information, but this has, honestly, become a mess due to the creation of properties. My templates don’t work right, lists of recipe ingredients are a pain to create/set up, and I can’t see it properly. :frowning:

In a book note, I’m using aliases, tag, title, author, publisher, publish (publication date), total (I think this is number of pages), isbn, cover (image link) status, rating, read (date).

I don’t think I picked these: I think the plugin I’m using had the template already established.

In recipes, I’m using name, source, ingredients, scale, photo_thumbnail, image_url, total_time, description, rating, servings, main_ingredient, tags.

1 Like
36

Nice! Do you have file properties constantly displayed in side bars and if so where exactly?