The main issue with your query and keeping multiple meeting references within the same note is that instead of having inline fields with just one value, you get inline fields with multiple values.
This can be seen if you open up your query, like in:
```dataview
TABLE attended_by, when, row.where, subject, hosted_by
WHERE file = this.file
```
If you are using the Prism theme, this’ll show up as:
This in fact one row of data (see the (1)
in the upper left?), where all columns except the first have two values, one from each meeting. Also note that in the attended_by column, there is just one field which contains three links concatenated to that one field.
When dealing with lists you’ll have to start using stuff like contains(where, "Room 301")
instead of the single value comparison of row.where = "Room 301"
. In your case, however, this will not make a lot of difference since this will not separate out all the other information related to that meeting.
Page vs list scope
There are two ways to split the meeting information apart, one is to have separate notes for each meeting and leave the inline fields in the page (or note) scope like all your fields in the example are. Separate notes would mean just one field per page. However, I do understand you don’t want to do that.
The other scope available, as of now, for dataview is the list (or task) scope. This does require more markup, so one variant of this is as follows:
- (Subject:: New widgets factory) – (when:: [[2023-03-31]]) in (where:: Room 301). [Hosted_by:: [[Andrew]] ], [Attended_by:: [[Bob]], [[John]] ]
- (Subject:: Sales Budget) – (when:: [[2023-03-30]]), (where:: Room 205), [Hosted_by:: [[John]] ], [Attended_by:: [[Frank]], [[Mary]], [[Bob]] ]
```dataview
TABLE WITHOUT ID
item.Subject as Subject, item.when as When, item.where as Where,
item.Hosted_by as "Hosted by", item.Attended_by as "Attended by"
FLATTEN file.lists as item
WHERE file = this.file
```
Still using the Prism theme this displays as:
Do note that alternating between [field_name:: value]
and (field_name:: value)
respectively shows and hides the field_name
from the output, while it still keeps the inline field as is. Also note that I’ve added commas, ,
, in the Attended_by
list to actually make that a list of attendees.
This output now presents two rows, since there were two meetings, and now you could have done WHERE item.where = "Room 205"
to limit to one of the meetings, or doing WHERE contains(item.Attended_by, [[Bob]])
(or similar) to get meetings where Bob participated.
The visual appearance of each meeting could of course be dealt with using CSS. Personally I tend to make the field names a lot more anonymous and “hidden” in the surrounding text. (Not quite sure why that doesn’t apply when testing with the Prism theme here)
However, the main point is that using markup similar to the example you’re able to group the various meetings into different scopes which allows for queries to address them as separate meetings.
Meetings in the frontmatter
Yet another option where you could group meeting information together better than in the page scope, is in the frontmatter. It does however have its own caveats, like yet another syntax, and links not being properly treated related to renaming and out- and backlinks, and so on. The latter can be countered somewhat using a plugin which makes the link in the frontmatter behave a little more naturally.
Here is how your meetings could look if entered in the frontmatter:
---
meetings:
- Subject: New widgets factory
When: "[[2023-03-31]]"
Where: Room 301
Hosted_by: "[[Andrew]]"
Attended_by: ["[[Bob]]", "[[John]]"]
- Subject: Sales budget
When: "[[2023-03-30]]"
Where: Room 205
Hosted_by: "[[John]]"
Attended_by: ["[[Frank]]", "[[Mary]]", "[[Bob]]"]
---
```dataview
TABLE WITHOUT ID M.Subject as Subject, M.When as When, M.Where as Where,
M.Hosted_by as "Hosted by", M.Attended_by as "Attended by"
FLATTEN meetings as M
WHERE file = this.file
```
The output would look the same as the previous.
So there you’ve got some more options, and explanations as to why you often see the recommendations to have meetings in separate notes as it greatly simplifies stuff, and how you still can have them within the same note and what that requires of the markup.