Is the properties of a Note similar to metadata?

Help
,
1

Hi all,

I’m new to the obsidian world. Also trying to figure out the best use of dataview. For what I take, dataview uses the metadata of a note to organize and filter them.

Does anyone know if the properties of a note are similar to the metadata? I thought it may be, but when trying to use the properties to filter notes, dataview doesn’t filter them.

So, my next question is, how are you managing your metadata? I mean, how do keep track of all your keys and values?

Thanks in advance!

JJ

2

Properties in Obsidian is (are) what metadata is elsewhere. Properties is like a local (Obsidian-chosen) naming convention, metadata is general but they are essentially the same.

Usually people keep their metadata in YAML/frontmatter at the top of the file, like so:

---
somekey: somevalue1
somekey2:
  - somevalue2
  - somevalue3
---

Many threads deal with populating notes with metadata with the Templater plugin and many with querying them with DataView.

2 Likes
3

Depending on how detail oriented you want to be I’d say there are three categories of metadata from my perspective:

  • Properties – As found in the frontmatter/YAML of a note, i.e. property: value
  • Dataview’s inline fields – Fields defined within the body text of a note, i.e. [inlineField:: value]
  • Dataview’s file – Within Dataview queries you’ve got access to this compound object which holds metadata on the file itself, such as creation and modification dates, but also the complete lists of lists and tasks from your note

The latter two are only available in Dataview aware contexts, but I do think of them as metadata available to me. One could also argue that some of the other plugins could offer means of metadata specially available for it.

Based on this definition I would say that properties are part of the metadata associated with a note, but it would be wrong to say that stuff like file.cdate or file.lists, or inline fields are part of the properties. Then again most people would understand you if you used properties, although imprecise, about inline fields.

Dataview should treat both inline fields and properties (as in whatever is specified in the frontmatter) equally, and allow you to work them without considering their origin. So if you’ve got a problem with that, please present the query you’re having issues with, and some example data which you thought should be included/excluded from your query.

There is an entire forum category, Knowledge management , which partially is devoted to this (and related topics), so it’s not easy to give a good and/or complete answer to your question.

A few pointers though, there is a panel in the right side bar (if you enable it) which allows you see all the properties (yet again, only those in the frontmatter) from your entire vault. This could be helpful identifying if you’ve added something with similar names and so on, and it’ll also list how many of each property you’ve used. A similar pane exist to get an overview of the tags you’ve used.

My personal preference, which is not to be taken as the ultimate goal, is to use tags mainly for tagging stuff which needs some kind of attention and have an intermediate long lifespan, and then I use properties for more descriptive information made for the long run. This sounds like a simple scheme, but I’m not good at keeping even such a simple scheme going.

The best advice I can give is to use some sort of tagging/metadata/link structure which makes sense and feels useful for you. Don’t implement some scheme just for the sake of that scheme, as if you don’t understand/agree/… with the underlying structure you’re likely to have problems following it. And you can always rework your scheme after a while when you start seeing more of a structure to your writings and needs to access your data.

1 Like