Sorry for the delay in my answer, but I want to give you a proper answer, with some examples, because you’re touching in on various key concepts, which can make it a lot harder or easier for you depending on the syntax you choose.
Field definitions in frontmatter
As I understanding it you’re aiming to group some information together to create a relationship (or link) between various other notes. Using the syntax you provided, you’re creating two disconnected lists. Or for the event::
definition it’s just a string, with actually no links stored (or queryable).
A better option if using the frontmatter I think would be to keep the relationship information together within one objects, so something like the following could work:
---
Tags: f55889
events:
- primary: "[[Note2]]"
relation: "owns"
secondary: "[[Note3]]"
- primary: "[[John]]"
relation: "owns"
secondary: "[[Xbox]]"
---
This defines one field, events
, which is a list of all those starting with -
, where each of those again have the fields: primary
, relation
and secondary
. A query displaying these values from the same note:
```dataview
TABLE WITHOUT ID E.primary, E.relation, E.secondary
FLATTEN events as E
WHERE file.name = this.file.name
```
Results in this output:
I’m using the FLATTEN events as E
to split up events
into its single events, and then display these. Names can of course be altered according to your will.
The downside of doing it this way, is that the links are not actually treated as links, so there will be no connection between Note2
and Note1
(given the query was in Note1
), nor between Note3
and Note1
. So no backlinks, and if you rename either note, it’ll not be propagated, and so on.
The plus side of this variant, could be some of the same arguments if that suits your needs, and in addition it’s kind of a clear markup. It can be changed into various similar markups, this is just the way I prefer to do this particular style of lists of objects in the frontmatter
Currently dataview doesn’t allow for list of objects to be defined outside of the frontmatter (or YAML). This is something which seemingly will be addressed in the new datacore plugin, if or when that is ready for us to use.
Using lists
However, I’m preferring to use lists for this kind of markup in most cases, as it allows me to see the linked text, and if formatted properly, I kind of like seeing the definitions.
So here is another example you could try in a note of its own:
## Using lists
- [[Note2]] (relation:: owns) [[Note3]]
- [[John]] (relation:: owns) [[Xbox]], [[Nintendo Switch]]
```dataview
TABLE WITHOUT ID item.outlinks[0], item.relation, item.outlinks[1]
FLATTEN file.lists as item
WHERE relation
```
## With multiple secondary relations...
```dataview
TABLE WITHOUT ID item.outlinks[0], item.relation, filter(item.outlinks, (i) => i != item.outlinks[0])
FLATTEN file.lists as item
WHERE relation
```
In my setup this displays as:
Sorry for the non-defined links which is a little dark, but you get the gist of it.
What I like about this setup is that I’m using the field relation
to help me detect which notes do have some relation between notes. I then use two implicit connections, where the first link in the list item is considered the origin/primary part of the relation, and any other links are considered secondary to the relation.
This scheme then allows for multiple kind of relations to be created. You could easily create relations like relatives, or ownership, or work relations, or whatever you can think of. Given proper formatting, you can also extend the sentences to make them more meaningful, but still be queryable using the same kind of scripts.
Imagine something like the following:
- [[John]] is the (relation:: father) of [[Mary]], [[Susan]] and [[Robert]]
- [[John]] (relation:: owns) an [[XBox]], [[Nintendo Switch]]
- [[Peter]] is the (relation:: boss)) of [[John]]
Given similar setup across your vaults, you could now write queries where you specify which relation
you’re looking for, and pull out who has which part of the relation according to the query above.
For example you could do something like this to check who is a father stuff in your vault:
```dataview
LIST WITHOUT ID item.outlinks[0]
FLATTEN file.lists as item
WHERE item.relation = "father"
```
Using a similar query you could check who owns an XBox, (which does get a little hairier as we need to do some trickery to keep the rest of the links as an item list.
```dataview
TABLE WITHOUT ID owner, ownedItems
FLATTEN file.lists as item
FLATTEN item.outlinks[0] as owner
FLATTEN array(filter(item.outlinks, (i) => i != item.outlinks[0])) as ownedItems
WHERE relation = "owns" AND contains(ownedItems, [[XBox]])
```
PS: I’ve left all the column headers as they’re defined, but you could of course rename them into something nicer.
In summary, using a list item to contain your related information opens up for easy querying of information in any given list item. If you then add some fields into that list item, the options are nearly endless. It’s just a matter of defining proper relations and being consistent in how you write stuff.
Sadly though, even though we’re now able to connect notes using the queries, we’re still not seeing direct links between the “Note2” and “Note3” from your original example, but given the relationship is defined in “Note1” there’ll be links from that to the other notes.
And if you choose a type of those connecting nodes it could show in either the local graph and/or global graph views.