Add Link-tags feature

[bruce]

@leekeifon

we may finally get more abstract power from the category theory mathematical model, which may indeed help structure our complex system, though I’ve not think through it yet.

I know nothing about category theory, but would just reiterate what’s developed into a mantra of mine:

Abstract theory that helps structure the UX in such a way that it is more transparent and clear to the end user = good.

This relates to the point that I and @cobblepot have made, and Ahrens has also made, about ensuring the software is presenting very low friction to generating content.

A user, then, must not be required to know anything about category theory to exploit it in the software, if it’s designed right.

[leekeifon]

Of course, you’re right, user doesn’t need to know about what the theory is and the theory may not do a lot good to the UX (maybe it will in some day).

My point is just trying to help address the idea of mine on link-tag and showing the possibility that category theory may guide us to build up a note taking system in a more consistent way.

[cobblepot]

@alan

I would argue against using link-tags for something like this. It creates a type of “Folgezettel” which, according to users at https://zettelkasten.de/ doesn’t really make sense with the volume and abilities of a digital archive.

I think it’s more accurate to say that according to @sfast at zk.de, Falgezettel doesn’t really make sense. If you search my name on that site, you’ll see I’m quite familiar with it.

The issue of how/whether/why to integrate hierarchies within and between notes is really, really, complicated!

[alan]

@cobblepot

I think it’s more accurate to say that according to @sfast at zk.de, Falgezettel doesn’t really make sense. If you search my name on that site, you’ll see I’m quite familiar with it.

There it is then I never know what others’ starting point is, and I’m still getting familiar with all the zettel discussions myself.

At the end of the day, of course, who cares what I think is a good idea! The link-tag implementation means anyone can use what makes sense to them.

[bruce]

I don’t know what I think about this, or how it relates to this discussion, now, but this seems a post worth reading? It’s more nuanced than the title suggests.

The Case Against a Digital Folgezettel

[bepolymathe]

Very interesting. I like the idea of inherited IDs. It seems to be an interesting hypothesis since I understood that the idea was also thinking about org-mode IDs especially for link management.

[shlevy]

@alan Was there ever a PR for this functionality?

[alan]

There wasn’t! All of my time has been spent trying to run research experiments and analysis without assistance during this pandemic I have barely touched org-roam in months! Some of my work is about to be finished though, so I might be able to pick this back up and create a PR in the coming weeks.

[gcoladon]

I just followed the link here from another post, and I am very interested in specifying link relations myself. I am curious to know what the most direct way to add in just the essential elements, which from my perspective are

a) a new relation field in the links table
b) the parsing of link text to separate title::relation
c) the placing of relation into generated graphs

[nobiot]

a) is probably not needed.
I think you can use the properties field and add a relation/relations as an element of the list.

I noted in this post, which i thought was related:

Gellish Knowledge Management

@zentr1c One of the most engaged posts of all time in this forum is about adding meaning to links in Org-roam. The thread itself has been dormant in this year for now, but I believe that many people are still interested in the topic. As far as I can see, the Gellish approach is one of many ways to add a meaning to links and does not look to be unique in design. For implementation, I think it is do-able and worth the efforts if someone is keen to drive this. Below is some rough ideas that I c…

If you execute this query in Emacs…

    (org-roam-db-query [:select [source dest properties]
				:from links
				:where (= type "id")])

You will get something like this below. I have added a column heading to make it easier to read.

#+RESULTS:
|   SOURCE (ID)    |   DEST (ID)      | PROPERTIES             
| 2021-01-18T130000| 2021-01-27T165658| (:outline nil)|
| 2021-01-18T152100| 2021-01-27T173744| (:outline nil)|
| 2021-01-18T152100| 2021-01-27T154809| (:outline nil)|
| 2021-01-18T165223| 2021-01-25T203301| (:outline nil)|

[nobiot]

@gcoladon not sure if you are on Slack; you migh benefit from this conversation

Welcome to your new HQ

[gcoladon]

@nobiot

@gcoladon not sure if you are on Slack; you migh benefit from this conversation

Thanks @nobiot, I haven’t been to Slack for a while, I will check that thread out

[jonathan]

@alan, has there been any progress on this? I’d love to test it out when it’s possible to do so. Is it compatible with V2?

[jethro]

The simplest way to achieve all this in v2 is to create link types for each kind of relationship you want, and have them all behave the same way as ID links. e.g. hypothesis-of:uuid, refuted-by:uuid. Org-roam will cache all links, and set the type attribute accordingly, from which you can make custom widgets.

[bruce]

@jethro

The simplest way to achieve all this in v2 is to create link types for each kind of relationship you want, and have them all behave the same way as ID links. e.g. hypothesis-of:uuid , refuted-by:uuid . Org-roam will cache all links, and set the type attribute accordingly, from which you can make custom widgets.

And, I only just learned recently, embark has support for running actions on in-buffer targets like this.

GitHub - oantolin/embark: Emacs Mini-Buffer Actions Rooted in Keymaps

Would be a good use case for this?

[msteffens]

@alan

A link-tag is extremely similar, but the context is the ‘destination note’, instead of the ‘origin’. If I write [[roam:NoteB::indexes]] it is conceived as:
(NoteB)-[:indexes]->(NoteA)
and if I write [[roam:NoteB::indexed_by]] it is conceived as:
(NoteB)-[:indexed_by]->(NoteA)

Hi @alan and others, many thanks for pushing link tags (aka “typed links”) for Org-roam!

I am not an Org-roam user but I came here in the hope to discuss link type syntax (and to ideally find a format that would work across different note-taking applications). In other places (see e.g. here), I’ve argued for a link format like this:

[[optional link type(s)::LINKID]]

Personally, I like that this link format can be read in a natural way. For example, when adding this link from within NoteA:

[[confirms::NoteB]]

this would be conceived as:

(NoteA)-[:confirms]->(NoteB)

In order to try out typed links myself, I’ve also implemented typed links for my own app. Personally, I find it really helpful to assign link types, visualise them in the graph, and to filter notes by link type.

However, having read thru this thread, I realise that it’s probably too late to discuss any link type syntax since it seems you’ve already settled for a different format (quoted above). Is this correct? Thanks!

[patched]

I have been experimenting with adding metadata for different metaphysical relations between concepts, mostly for “x is y”. I do it by adding to the end of the note for e.g. “Dog”:

* Relational metadata
** is
- [[Animal]]

This info can then be extracted from the db from the table links, column properties. I have used this to test some ontological hypotheses to find errors in my reasoning, with the help of prolog.

I’ve noticed this to be quite restricting however; Sometimes I want richer connections than “A is B”, “A contains B”, et.c… Sometimes I want “Given assumptions A, B, C, D, we can deduce E”, to be able to programatically find assumptions and conclusions of a proof. Sometimes I want note X to connect Y with Z as a thought experiment, and conditionally include it when testing metaphysical hypotheses.

It might be possible to model this in the same way, however, this seems much like a hack. It would be interesting to be able to attach arbitrary data structures of links to notes.

[doubleloop]

One facet of links that I would like to record is the date that the link was created. Chiefly to enable a list of ‘new connections’. In some sense this would be less of a tag and more of a key-value pair associated to the link.