Dataview question, when using Metadata Menu plugin as well

[Robiton]

Morning. I am new to Obsidian, but based on what I have read and watched, I believe it would allow me to collapse a legacy Evernote, a private Notion (used to use it at work, but they moved to Clickup), and a gap in Clickup for my work things that would have existed in a private area in Notion.

One of those is meeting notes. I watched this video and learned a lot, and think the setup for meeting notes will work for what I need. (https://www.youtube.com/watch?v=kqx6KHniMCc&list=TLPQMDgwMTIwMjQ3K1DcKywusg&t=2s )

Where my question comes in, is how would you query for the subfield of Company in Dataview, so I can create “views” of meetings by company (or further later on, by who I met with internally or by meeting type)?

Example of the fields I setup

Thanks in advance

[holroy]

How goes that after a property/field has been set? What is the markdown after insertion?

[Robiton]

It was created using the Metadata Menu plugin, and stored in fileclass fields.

[Robiton]

Looking at the Meeting Class source

[holroy]

I’m not sure I favor that field structure, but lets work with what you’ve got. In order to get to a given field within that Participants structure, you could either of the following, where the first relies on a bit of magic, and the other is slightly safer:

Participants.Company
 ... OR ...
map(Participants, (m) => m.Company)

If in addition you’d want to list just the pName of those belonging to the Acme company, you’d need to first filter the list to that company, and then map out the field you’d want. That could look like the following:

map(filter( Participants, (f) => f.Company = "Acme"),
  (m) => m.pName )

The last operation is the map(), so let’s start with the filter(), and that takes two parameters, the list which we want to filter (aka Participants), and how we want to filter it aka ((f) => f.Company = "Acme" ). This last part reads as for each of the list we’re working, let each item be stored into f and then let us do the expression using that. In this case, check the field Company and see if it matches “Acme”.

After the filter has filtered out all those Participants from “Acme”, this is passed as the list into the map() command, which kind of works the same way. Here I’ve used m to denote each of the items we want to map, and chosen to list out the pName of that item.

---

And just to be clear on what we actually see in your “Example” image, there we see a property list named Participants, which in this case has only one item which is a compound object. (Each item is separated by that leading - in this case before the pName.) The compound object has three sub-fields, namely: pName, pDepartment and Company

[Robiton]

Thank you, this is good information.

Let me ask something a bit different. You can see the intent of being able to group a person by their role and their company, and being able to use either of those (or their name) to track meetings they were in. In Notion, this was simple via linked tables, though it did get long on some users.

Do you have a better idea on how to do this in Obsidian, versus what the gentlemen was suggesting in the video about using sub fields?

[holroy]

I might have misread parts of your structure, but I do like to keep it simpler. Like why group the type and the date of the meeting into Logistics? Why can’t they be separate properties of the meeting?

And why duplicate the information on the people participating in the meetings? In most cases a person will keep their position and company for ages. And do you then need/want to keep track of when they switched careers? And how would you do that? This also means that at the end of the day, you’ll keep on duplicating this information for each meeting. And you’re having a harder structure to query.

I believe, without looking too much into it, that the meeting in itself is a strong enough structure to allow for it not having to much substructures. In other words, I’d have the partipants as a list of person links, use date for the meeting date and a global type field to denote this is a meeting. If need be, I’d subdivide the meeting type through nesting.

This would lead to an example meeting like:

---
date: 2024-01-14
type: meeting
participants: 
- "[[John Doe]]"
- "[[Jane Smith]]"
---

You’d still be able to lookup company and/or roles of a given person through their note, but the meeting note would be a little cleaner and easier to work with.

Disclaimer, this is said based on rather limited knowledge of your use cases, and what your aiming to get out of your notes.

[Robiton]

That does map better to what I did in Notion, I had a people table that had all the data, and I used the name field in the meeting as a relation to the people table, so I could select people, and if they were not in the people table, I would add them. Doing a lookup here, sounds viable.

Meeting type was a drop down from like 5 options, which was setup in a view to filter by type. Maybe a query solves that.

You have given me a lot to think on, thank you for that,.