Currently, as of dataview v0.5.55, it doesn’t support object definitions for inline fields, so that syntax of object(...) is extraneous, and it’s just parsed as text. Try out the following in a new note:
---
tags: f54632
---
- [ ] using "object" defintion [coined:: causality] [causality::object("cause", "sleepless", "effect", "headaches")]
- [ ] Using list of string defintion [coined:: causality] [causality::"cause", "sleepless", "effect", "headaches"]
## Task query
```dataview
TASK
FROM #f54632
WHERE !completed AND
coined="causality" AND
econtains(causality, "sleepless")
```
```dataview
TABLE WITHOUT ID T.coined, T.causality, typeof(T.causality), econtains(T.causality, "sleepless"), econtains(T.causality, "sleep")
FROM #f54632
FLATTEN file.tasks as T
WHERE !T.completed AND
T.coined="causality"
```
The table display the following (if using Minimal theme ) :
Here we can see that the first task is having a string (or text) with the “object( … )”, whilst the second line has an actual array of the causes. It turns out that the econtains() falls back to an ordinary contains() when it matches against a string vs an array. However, in the last column you see that it’s better in most cases to use the econtains() as it requires a match on the entire text (aka cause), and not only a part of it. I reckon that in most cases you don’t want a hit for “sleep” when the cause is “sleepless”.
In other words, I would suggest removing the object( ... ) surrounding the list of causes, and use econtains(causality, "sleepless") to match exactly against a list of causes.
Variants exists to properly eliminate the feature of matching on “sleep” if causality only had one item, but I’m not sure if that edge case is worth the bother or not.