I’m creating a contact database (name, phone number, etc).
Obsidian’s Dynamic Views feature says it uses “data stored in note properties”
Question: Will this Dynamic View include dataview metadata inside the note (via the :: syntax)? To future-proof my notes, should I put all my contact properties into Obsidian’s Properties area (i.e., YAML/frontmatter), or is it safe to put some properties/metadata inside the note as inline fields as key::value?
Just wanted to get insight from people working on the feature since this is a key consideration on how I structure the properties of my notes.
The double colon syntax is something that Dataview uses for inline fields, and I’ve not heard anything indicating that it’ll be part of the dynamic view feature. That being said, there hasn’t been a lot of information about what is to be supported in the dynamic view feature.
So the safest option would be to use only properties (aka YAML/frontmatter). If the dynamic view feature will support some inline variant it’s not a given that they’ll opt for the syntax used by Dataview. But then again, it shouldn’t be too hard to use some regex magic to convert into the new format, if we’re not very unlucky.
In other words, I’ll (as an avid Dataview user) continue to use both properties and inline fields until the dynamic view feature is implemented, and I reckon we will be able to convert/transfer/mitigate into the new stuff when that time arises. But I’m not going to defer from using the option available in Dataview based on little-to-no information in the new feature.
Disclaimer: I’m not part of the Obsidian developer team, and I’m just a volunteer helping to extend Dataview occasionally when I’ve got the time and my pull requests are accepted at github
Why exactly? Using Obsidian doesn’t offer much advantage. Dynamic Views are designed for querying generic notes without much other special structure. The core use of Obsidian remains as writing text and/or producing notes using Web Clipper and not as inputing data items.
I’d love to see a list of “core uses” since I’d like to expand Obsidian’s function in my life as much as possible.
For me, contact database is a natural extension to my journaling and meeting notes. Here’s a simplified structure:
Every [day] has a note
Every [meeting] links to the [day] along with every [person] who attended and the kinds of [topic] discussed
I can then go back at a topic to see who I talked about it with. Or if I’m about to meet someone, I can look him up and see what days we met and what we talked about.
With Dynamic Views, I imagine filters like (1) birthdays coming up, (2) friends I haven’t seen in a while, (3) list of people who I talked about a particular topic, etc etc
I think this sounds doable with Obsidian. However how would you use inline fields?
(1) birthdays coming up—I would probably do this with 3rd party calendars since calculating birthdays requires many functions and these functions may not be offered by Dynamic Views
(2) friends I haven’t seen in a while—this also requires date arithmetic and possibly implicit fields
(3) list of people who I talked about a particular topic—this is straightforward query of backlinks with some additional filter
I think (3) is the closest what you would want to expect from Dynamic Views since calculations would make Dynamic Views way more harder to implement in a sustainable way. Also (3) requires you to specify items as persons or conversations since many types of items can link to topics.
For contact cards, Obsidian Properties are not ideal if there are multiple properties that start off very similarly, like Workplace_Current, Workplace_Prior. And Obsidian’s Properties do not handle tags very well, without an autocomplete feature.
For a separate use case, inline fields are useful for Obsidian Publish. Right now, the frontmatter is not viewable. It’s hidden. So that’s a clear trade-off.
And the mobile experience for Obsidian’s Properties is not very good. The key value only displays about 9 characters before getting cut off “…” to accomodate the value column, whereas inline would show everything clearly.