Double-colons as a delimiter for a link type prefix are already used by other tools (e.g. Semantic MediaWiki) so this would ease interoperability.
Also, this syntax travels with the link, and as such can be used inline. And it doesn’t spill outside of the main link delimiters ([[...]]), and would be rather straight forward to parse. In addition, it could also allow to set multiple link types, e.g.:
[[based on::confirms::LINKID]]
Finally, as discussed by @Emile for his Neo4j Graph View plugin, this could even support key/value properties, like:
As you can see here the data model consists of Nodes and Relationships. And both nodes and relationships will have properties associated with them. And together all of them will make a data model which will give us the better visual understanding of a dataset.
Properties are information associated to nodes. For example, if Wikipedia were one of the nodes, it might be tied to properties such as website, reference material, or words that starts with the letter w, depending on which aspects of Wikipedia are germane to a given database.
Labeled-property graph
A labeled-property graph model is represented by a set of nodes, relationships, properties, and labels. Both nodes of data and their relationships are named and can store properties represented by key/value pairs. Nodes can be labelled to be grouped. The edges representing the relationships have two qualities: they always have a start node and an end node, and are directed;[10] making the graph a directed graph. Relationships can also have properties. This is useful in providing additional metadata and semantics to relationships of the nodes.Direct storage of relationships allows a constant-time traversal.
These are interesting points. Currently, for Neo4j Graph View, I’m having both a list of typed links like - hasTopic [[note]], and like @msteffens mentioned, I’m thinking of adding the double-colon syntax.
What could be changed here is to move or also allow the list of typed links within YAML frontmatter. Personally, I like seeing them rendered, though. The double-colon syntax would also be completely optional, so complicated syntax is hidden from novice users.
Furthermore, I think an inline syntax like double-colon is important! This is because it’s much more natural to write linearly. If you mention some fact in your text that you want to annotate, it wouldn’t be natural to move to the frontmatter to add this fact in the typed link syntax another time.
@tuckytoo
The last code-block in the article about the Gram makes it confusing / does not make sense to me.
IMHO, (c {when:date`2021-01-21`})
should refer to <-[:Read]-
instead of (c:Person)
If it is possible to refer the link as <-[c:Read]-, then it is more useful.
Can anybody contact the author of the article - Andreas Kollegger? I do not have Twitter or GitHub account. @akollegger
Your observation makes sense to me.
You might imagine assigning a property such as birth date to node c. e.g. (c:Person {born:‘2021-01-21’}), but agree that the date property for when read makes more sense on the [: Read] relationship than the (c: Person) node.
For what it is worth, Gram seems to come from the “Cypher” query language of Neo4j and cypher allows typed properties for both nodes and relationships.
@Emile is a bit of an expert with neo4j and may have a perspective…
I found this thread as I’m in the process of restructuring my vault to better expose the relationship between pages, e.g. if page is a variation, aggregation or contraction with another.
Work-around, not ideal: rather than linking directly in the page, I’ve rewritten my links as footnote reference, and then tagging the footnote itself with the relationship. In the example below, “AG” standands for “aggregation”.
The benefit of footnotes is that it allows for descriptions and elaboration of the relationship.
Interesting use of unicode! I’ve experimented with using symbols in a similar way, for example using one of the unicode bank branch codes to denote a branch from a line of thought, e.g. ⑆ [[link to branch]].
But so far I’m not needing that particular case, though I am using aggregations adopting the term “MOC” from Lion Kimbro & Nick Milo. I’m using unicode / emoji directly at the front of the note name for those.
Example:
✧ mini-MOC
MOC
That helps at least distinguish them as aggregations, directly in the filename.