The behavior of frontmatter version of tags seems finicky. I have mine listed as tags: [work, topic/subtopic] etc without the hashtags or the quotes but definitely as separate list items! I don’t remember whether I got that from the Obsidian help or a forum post here. I know that hashtags without quotes is bad in the frontmatter - it’s interesting to see that quotes make them work!
Yes, that seems plausible, if it was before looking for tags with “contains” for example. Thank you for providing the best example I’ve seen of what that mysterious “Function Vectorization” comment at the top of the Functions page for DQL means! The rest of this post is purely for conceptual interest, no practical advice.
What is Function Vectorization?
Let’s make 2 items in some test page’s frontmatter, using the example from your post (but without the # since I want to have 2 items so they can’t both be called tags):
thing1: [" dashboard/people work friend "]
thing2: ["dashboard/people", "work", "friend"]
thing1 is a list containing a single string and thing2 is a list containing 3 strings; we can show this in a table:
TABLE thing1, length(thing1), thing2, length(thing2)
FROM "testFolder"
WHERE thing1
You’ll likely see one bullet under thing1 and bullets next to each of the three items in thing2, and the lengths are 1 and 3 respectively. Possible other experiments (aka dataview table rows to make): turn each thing explicitly into a string of text via string(thing1) or via join(thing1, "!!! ") and see what they look like and their length. Can you change the join function call to get the same behavior as string?
Do my fields contain “work”?
Ok back to what you actually wanted to do - find out whether some word/item/string of text is inside these things! From the Functions page again, contains(object|list|string, value) will check to see if the value is in the object, list, or string and return an answer of true or false. I am confident that if I add a row to my dataview table with contains(thing2, "work") the answer will be true since “work” is one of the three items in thing2’s list. But thing1 only has one item in its list - that whole long string! If thing1 was just a long string without the [] around it, I would also be confident that contains(" dashboard/people work friend ", "work") would have an answer of true. If we weren’t using dataview, it would just be too bad that long string is inside a list. But, Dataview function vectorization to the rescue! From the very top of that Functions page,
Most functions can be applied either to single values (like number, string, date, etc.) OR to lists of those values.
So contains will be applied to each of the strings inside each of the lists and both thing1 and thing2 will give answers of true!!!
TABLE
thing1, thing2,
contains(thing1, "work") AS "work in 1?",
contains(thing2, "work") AS "work in 2?"
FROM "testFolder"
WHERE thing1
Note: “AS blah” just renames the column header to make it shorter, you can take it out.
This seems to match the old behavior you were getting with tags.
Variations (aka more table rows to try): Do either thing1 or thing2 contain “work friend”? What about the exact item “work”? (Use econtains instead of contains for an exact match; it’s not documented on the Functions page yet but it exists in the updated dataview plugin.) What string do you have to use instead of “work” to get econtains(thing1, "work") to give an answer of true? Do any modifications or additions you can think of to thing1 and thing2 and see if the answers to queries in this post still match your expectations.
Guess with no evidence behind it: maybe dataview switched to using econtains to check for tags?
Perhaps one of the experts in this forum can answer!
