Die onderste link wordt veroorzaakt door deze query (dank Joost Plattel ):```oqlname: "This day in my history"query: {$and: [{"path": "'Deze dag op"}, {"title": "'11-04"}]}template: 'list'fields: ['title']sort: 'title'badge: false```Deze query verwijst naar een uniek .md bestand met als titel de maand en de dag van vandaag.Zo heb ik voor de 365 en soms 366 dagen per jaar een uniek bestandje.Door op de link te klikken kom ik op de pagina van vandaag in mijn persoonlijke geschiedenis:

ew, show all notes created today on daily note with DD-MM-YYYY? .t3_1689wtl._2FCtq-QzlfuN-SwVMUZMM3 { --postTitle-VisitedLinkColor: #edeeef; --postTitleLink-VisitedLinkColor: #6f7071; --postBodyLink-VisitedLinkColor: #6f7071; } Tried all the stuff I have seen, simply get an empty table. Any ideas?If anyone has a way that would link it on the graph too, that would be great. Thanks :D

Anybody using this approach to manage contacts? How?

DataView Habit Tracker

Some conflicts and misreading of what’s the structure of the metadata. When you create some tag in the content - #tag - it becomes a “real” tag to Obsidian and to dataview (an implicit field - file.tags). When in frontmatter you write tag: [one, two] or tags: [one, two] it happens two things: Obsidian (and dataview) read the values as real tags (#one and #two) and for dataview they’re target by file.tags (or file.etgs - see docs for understand the difference) - and attention: file.tags are always an array, even if only one value… even if you write tags: one, two But for dataview tag: [one, two] it’s also a normal field with the key tag (or tags) - that’s why if you write tags: one, two it’ll be read as an array if targeted as file.tags and a string - “one, two” - if targeted as tags As normal tags they’re metadata at page level, not at task level or lists level (that is another thing). As tags field it’s also a page level metadata. Topics above are intended to explain the difference between targeting tags or file.tags. And as file.tags they’re page level. So, if you ask for tasks to be grouped by a page level (parent level to tasks), there’s no way to you achieve what you want in that way… because the file.tags is a list of tags, not a flattened values (maybe with another query, with the flatten command…) A second point is related with the conflict you create when you’re using a taks query with the key tags. Why? because task query is a little confusing… it works in two levels at same time: at page level and at tasks level (a file.tasks sub-level of page level). And the conflict exists here: inside tasks level there’s an implicit field called “tags”, i.e., a field for tags inside each task text. For example: - [ ] this is a task - [ ] this is another one with a #tag in the text in this case the “#tag” is a page level tag but also a task level tag. It’s possible to filter tasks with a specific tag inside: TASK WHERE contains(tags, "#tag") This to say: when you write in your query GROUP BY tags it try to group by the tags inside the task level, not by the field you create in the frontmatter (a conflict because the same key field). In your case, because they don’t exist the result is: (2) - [ ] Task 2 - [ ] Task 3

I came up with a couple of criteria to help identify practical uses for the Dataview tool, over say, a embedded search query. Here are a few of those criteria: Use to access or summarize frequently-accessed data.Use in situations where the data is dynamic, and can change over time.Use to help automating a process

> possibly useful quote that supports my argument - keyword:: #representation_of_race #western #masculinity - film:: [[The Searchers]] - project:: #CLASS101 - comments:: this is really great, should use it in section B!