This is a feature request:
This would allow us the use the type of a link to identify a group of similar links between notes and add specific information to each link (like a keyword).
Would be a great improvement for me.
Do you need to create lots of named attributes?
Would the comment field be of use here?
Would a single dictionary perhaps be adequate?
for me any place for the additional attribute would be fine - $Name and $Type for a link maybe - I think it will be important to see the value of the attribute in the Map view or the link browser?!
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.
Hello Mark,
thank you for your detailed comment and of course (how could it be otherwise) a seemingly small change comes with some after effects.
For me the connections between the notes are very important. I think Michael also uses the connections very extensively. The type of a connection, from my point of view, is for classification.
A note can have different links, each with a different type (link to other content notes, link to authors, link to products…). That’s fine and I like to use that.
Now, however, I also build links automatically based on keywords. Note A has n keywords and note B also. The links based on keywords all have the same type. This is important because if I want to modify the automatically created links again at a later time, I need to be able to identify the type of the links.
Currently I look at my map or list of inbound and outbound links and see the same type everywhere. But I want to be able to see which keyword is behind each link. If I could add a name of a link and that name appears, that would be a big information gain. I would focus more on the color or pattern of the links when displaying the type and show less the name of the type. Or to be consistent with current versions of TBX: if the new name attribute is not set, then the type will be displayed.
Showing the name of the type just leads to a lot of redundant information. To assign a separate type for each keyword is prohibited for two reasons. It would lead to an inflation of the types and I can no longer recognize and remove all automatically generated links.
OK, so what I think you are saying is I have lots of note linked via type ‘keyword’ to a note describing that keyword, but I can’t tell from the link which keyword(s) are linked to the note"? If so the family of ‘linked’ operators cover this (linkedTo(), linkedToOriginal(), linkedFrom(), linkedFromOriginal() - more on linking operators). N.B. linkTo() != linkedTo(), as the first makes a link whilst the other asks if such a link exists. Because if using agent actions we are working with aliases, this is why the linkedToOriginal()and linkedFromOriginal() operators are there so that we can interrogate the original note’s links from the context of the original.
A logical place to put this extra info is in the link’s comment. Now linkTo() (and sibling operators) can’t directly set a comment at link creation (feature request idea?) but they could call eachLink() for either source or destination and iterate through to apply the desired value as the comment field.
So I think, based on the info suppled, the scenario is:
“whilst doing [process] in [context] I want/need to see [calculated info] but there is not [calculated info operator] and/or a way to show [calculated info]”
I’ve suggested a (partial) solution based on existing link operators.
The side that is still unclear is how/where you need to see the info. IOW, taken out of the lovely mental picture where anything is possible), assuming the link type knows the desired info, how do you wish to use it/display it. I ask partly as it might influences any improvements changes in the way the information might be stored/set.
We also need to be conscious of scale. I know I get criticised for this but what works wonderfully in a doc with 40-50 notes and a few link types is different to a doc with 000s of notes, 000s of links and now possibly 00s of comment types that all need to ‘just’ appear when needed. Again, consideration of this, might affect which solutions are sensible as if they work in a small test but not in a mature doc, there’s no real gain.
Links as first class objects (i.e. more like a note than data on the association between two notes) is the lurking element here but I sense embracing that would be a major change to the app so not a choice made lightly.
It would be interesting to har what others can/can’t achieve putting ‘keywords’ in a link comment. If nothing else it might sharpen the focus on what’s missing in terms of a functional as opposed to aspirational description (I don’t mean the latter as snark, but in terms of practical clarity). I’d give it a try myself but I’m a bit busy right now to start such an open-ended test.
HTH 
Interesting. Do you want the LinkTyp to be the keyword or do you want a set of keywords to role up to a particular type. All of these could be easily managed in today’s action code.
I do want the type to be the same for all links I set, but I want each link to have a unique name.
I need the type to access all links with this type and remove them if I need to. If I would set the link type to be the keyword I will not be able to separate those links from manually created links.
Example:
Now I run a script to link the notes with matching keywords. Note A and Note B would have to matches. Since the link type for all links I set by code is “justmylink” I will get only one link between note A and B. That’s fine for me even if there are two keywords that match.
If I look at the Map view I see the link named “justmylink”. Same in the link inspector. But all my links created by code will have the label “justmylink” - so this information is of no use for me.
If I run my code a 2nd time first I remove all links of the type “justmylink” and then create new ones. If I would create the links and name the link type with the keyword I would no be able to remove them later.
Actually, did we not address this a couple weeks ago in our meet up? I certainly believe I did in my last “Becker’s Patreon Session.” Let’s hop on a zoom.
This will not address your requirement, but the discussion beginning with the post below seems pertinent to your overall idea. However, it is rather long and, indeed, inconclusive.
I just fixed a lot of my dyslexic typos in the linked thread—sorry for missing those before!
Also it’s pertinent to point out that in the imminent Tinderbox release, not only will eachLink() read (almost) all facets of links but that all except anchors and calculated facets (e.g. isFirst) will be editable too.
Action code operators for links tend to reflect the fact that links are directional and are addressed—in the UI, at least—via the source note only, with Roadmap and Hyperbolic view being notable exceptions.
Whilst the ‘neighbouring’ item operator group, e.g. neighbors, have a bidirectional equivalent (neighbors2), perhaps the linkedTo/From() original need a bidirectional version too.
Thus I’d propose4 anyLinksTo(scope, type) operators including to/from/originals forms, where for note(s) at scope both inbound and outbound links are inspected, filterable to link type type.
Side note: in
links()the type argument is actually evaluated as a regex pattern (not just as a string literal) but I’m not sure if this is true of other linking operators. If not, I think it might be useful.
Also, imminent changes/improvements to Hyperbolic view—as have been discussed in some public meets–may offer a better visual way to investigate link patterns. Of course, in Hyperbolic view the app drives the layout—compared to map view. I thought this would matter, but find it doesn’t, especially as the view looks across the whole document _via links—so is agnostic to the container boundaries of maps.
@webline and I had an offline conversation on this and explored the idea of using the title/anchor field of a link as the new attribute. He is exploring this now.