This is interesting, but the practical use is still a bit opaque. Currently, if two notes need to be linked using more than one link type, this requires multiple links—one per link type. Note too that action operators for working with typed links assume the same. Changing a link’s type is possible via the UI (Browse Links & Roadmap) via action code—see eachLink(). The latter requires making a new link of the desired type and removing the link of the non-desired type. The latter reflects what’s happening internally even if the UI method makes it look like you are simply changing a property (‘type’) of the link. IIRC, having an action operator that allows link type changing has been asked for but I assume it hasn’t happened as it causes complexity that is hidden from the user.
Separately, all links have Comments, currently both set and read_only_ via the UI (Browse Links & Roadmap). At the risk of raising the backstage curtain, but to forestall possibly asking for the soon-to-be-available,
eachLink() will enable editing (changing) comments and the visual properties (visible, dashed, dotted, bold, broad, linear.)
For consideration here is the fact that we’re turning—albeit not intentionally—links into first class objects rather than a list of relationships between (note) objects. Traditionally, the extra info we might place on a link is stored in either the source or destination note and read/retrieved from then.
Another contingent aspect is that for years link types have more often been used as visual (like) line descriptive labels than for functional typing. IOW, the text of the ‘type’ is a label primarily for visual consumption in map view. This is important as with forthcoming maturing of Hyperbolic view, the use of link types, for indication link intentionality, becomes more practical. Thus I wonder if we are approaching a point where the visual prose (map & timeline) visual label and the likely more terse link type need the chance to differ. One possibility might be to use the comment for map labels, but I think it makes sense to allow for a (visually hidden) comment link payload). Note, none of this stops type and label being set to the same value—i.e. mimicking current behaviour—whilst allowing more nuanced use as hinted at by the @Detlef’s requests above.
Implicit here is the (map & timeline) visible link labels need to show more that just link type. That implies the notion of a link label as several different link properties can/will be shown.
Not considered, but should be is how much extra information is to shown in the label and as how many pieces? Why? Because, it’s little help is the automation side (action code) can create a complex label but there aren’t complimentary tools to place the labels. The more link and the larger the labels, the looser to the packing of the map needs to be to accommodate the labels. If as users we think the app should ‘just’ do this for us then we need to surface or unstated assumptions as to what usable position means, i.e. looks line on screen.
It might be, if links are going to carry more data, that this is exposed in a tool-tip manner, to avoid visual poise. Of course, with all this extra info in play, we need to consider the effect of the responsiveness of maps (recognising we’re pitch even more work into constructing the map).
One could pack a dictionary of data into a link comment: I think it’s possible now (albeit hard to ‘see’). But, I’m not sure that’s a wise path, for the moment, as I suspect that’s a context where the app design might expect a user to place and interact with code—‘code’ in the sense that a dictionary is a collected set of data so requires some manipulation to set/get a given values or to display the whole as a form of table.
Please don’t read any of the above as push-back against the ideas, I’m simply looking at the practical implications and where they may, inconveniently, butt up against the existing app architecture. I think the latter is pertinent, especially if there are different ways to the same end that don’t imply undue change in the background structures.