Some more thoughts on linking in TW (aliases, display text, and relationship types: Oh My!)

[dieg...@gmail.com]

Hello all,

I thought again about one of my previous posts, and I thought I'd try reposting it and editing it to encourage more conversation/ideas around this topic.

In my mind, linking is one of the two major pillars of TW (searching/filtering being the other - why I think a lot and comment a lot about search). If I want to link to a tiddler there are four (used to be three) issues of concern:

1. what I want to type

• Aliases provided by the un-link plugin are magical here! A tiddler with "long title of method" can save me many keystrokes (and potential typos!) if I just type the name of the alias.
• Critically, this is decoupled from where I want the link to go, and what I want it to render as. I don't ever want to type "a very long title", or if the core also supports uniqueIDs, I don't want to type timestamps. 
• Something that I think should be incorporated into the core (!!!!) (or at least with uni-link) is the Edit-Comptext dropdown plugin. This plugin already lets you define custom dropdown templates, so its natural to incorporate the filters uni-link provides. 

2. where I want the link to go

• If we're not just focusing on aliases for a second, this isn't as straightforward as I initially thought - frequently I want a link to go to a tiddler with a specific title (this is the obvious case).
  
• Sometimes I want a link to go to a specific tiddler, regardless of its title. For example, my TW is constantly evolving as my system of knowledge is evolving - I rename things, reorganize, etc frequently. If I rename a method, or person, etc. all of my links to this tiddler no longer work
  
  • (there have been previous discussions of renaming tiddlers triggering a search/replace).
    
  •  The recently introduced relink plugin solves this particular problem!
    
• I am more interested in being able to link to a tiddler by some kind of unique ID (for example, created timestamp, or another field) - that way, renaming a tiddler's title does not trigger massive textual changes in the rest of my tiddlers
  • I use version control, so it's a bit annoying when I rename one tiddler, my commit object contains changes to 20 other tiddlers whose links to this one tiddler also had to change.
    
  • Uni-link address this issue, by introducing a (hopefully) unique field: aliases.
  • So now I can link to [[coolMethod|?]] regardless of the actual title of that tiddler! This is a wonderful feature!

3. what I want the link to render/display as in view mode

• TW already supports some version of this, as sometimes it's appropriate to render a tiddler's title, other times its caption. I just want to extend this so that the user has more fine-grained control over this.
  

4. What kind of relationship I want the link to represent

• Thanks to the illuminating typed links thread, I've come to realize this is also a central concept in linking!
  
• Coupled with the ideas given in the recent "Athens" thread about thinking of your knowledge graph more formally as an actual graph, it makes sense to think of the kind of connection you want to represent. 

Link Syntax:

Note: below I introduce some spaces to help with legibility, not paying attention to the fact that they actually aren't in the syntax.

Currently, the core supports two link types:

• [[ link target ]]
  
• [[ Display text | link target ]]

Uni-link introduces two more:

• [[ alias name |?]] - links to a target that has 'alias name' in its aliases field. Note you did not specify the target name at all! Only its alias!
  
• [[ alias name |? fieldNameToRender]] - links as above, but displays not the alias name or the target name, but the content of the field given

We see that the last uni-link syntax gives the following:

• ✅ lets me type a short alias for any target
  
• ✅ allows me to NOT have to specify the target tiddler with a long name
• ✅ changing the target tiddler name does NOT affect any alias links
• ✅ lets me easily specify what I want the link to display/render as

The only missing feature (besides the autocomplete given by the EditComptext plugin) is specifying the relationship type.

I have no idea what syntax would "make the most sense" but I can propose some:

• relationshipType::[[ aliasName |? fieldNameToRender]] - like in Roam?
  
• [[ aliasName |? fieldNameToRender | relationshipType]]

I'll let others think of a better syntax given TWs internals.

I'm anxious to hear others thoughts!

Diego

[Joshua Fontany]

If we did add a relationship type to links, it helps to unpack the WikiText version of Links into their <$link> widget equivalent.

[[LinkText|CurrentTiddler]] unpacks to the following "parse tree" json in the internal javascript
```

{ type: "link", attributes: { to: {type: "string", value: link} }, children: [{ type: "text", text: text }

```

which is the equivalent to typing:

```

<$link to="CurrentTiddler"><$text text="LinkText"/></$link>

```

Now, as we want "typed" links to other tiddlers, and probably not to external resources (hey, make a tiddler that points there), then we can re-use the pattern fro the "extended external link" WikiText, and the "extended image" WikiText. It would look something like:

```

[type:relationship[LinkText|CurrentTiddler]]

```

which would then render as

```

{ type: "link", attributes: { to: {type: "string", value: link}, type: {type: "string", value: type} }, children: [{ type: "text", text: text }

```

and be the equivalent of typing

```

<$link to="CurrentTiddler" type="relationship"><$text text="LinkText"/></$link>

```

So, you could not use referenced (transcluded, macro, variable) data for the type in the WikiText version, but you could in the full Widget version.

Something to think about....

Best,
Joshua Fontany

[dieg...@gmail.com]

Joshua

Thanks for your thoughts.

To others, can someone help me understand why my posts often don't get many (if any) response?  The first time this was posted it also inspired almost no response. This time as well. This happens to several of my posts, so I'm curious as to my "disconnect" with the community somehow.

[David Gifford]

It's pretty random. Sometimes I get three or four people with replies and solutions, other times I have to bump threads to get them noticed. Also note that if you post on a Friday night or the weekend, you may not get a reply until the new week. At least I have found that at times. I did read your original post, but you are asking for input on something above my technical skill, so I didn't have anything to say. Blessings

[maki aea]

hi diego, re: the posts thing, for me part of it is i am mostly on mobile, and it is relatively painful (probably just haven't figured out a good way) to reply to messages on google groups, without using a text editor and copying the text back in to a message to post. maybe there is a guide somewhere for gg newbies but this page suggests it's intended behaviour https://gatlabs.com/blogpost/improved-mobile-interface-for-google-groups/

it makes it hard to continue to reply in a conversation as there is a lot of friction for a mobile user, so the bar for replying is raised somewhat from where it could be.

in agreement with david, posting time is probably relevant, in this case i can reply only because pretty much my only free time during the week is right now and i can switch to an ipad to do it!

regarding your original linking topic, i might be speaking for a lot of newbies who have never heard of unilink until now, and like me are still getting our heads around the "extended external link"! but reading your post and everyone's replies lets that knowledge percolate in (i hope) and kickstarts my own thinking about "issues of concern", which is super helpful, so thank you for posting, though i wouldn't normally reply as i currently don't know enough of the background to this to contribute something directly useful.

so it got me thinking about things like discovering anwiki exists; for new users we are heavily dependent on search as we don't know enough yet to see why example wikis might be relevant to our particular situation (david's list)

but this also makes the window for contributing to gg posts very narrow, unless you are already at the matching level of knowledge, AND watching the group/able to find the post, AND have means to reply, AND have something ready to contribute

so for example here a tw newbie might not understand yet how super interesting your topic is, because it is so "meta", i.e. thinking-about-thinking; or another example peter's firebase backend on the tw dev gg/tw github discussion which is also super cool and useful, or, well, pretty much everyone's contribution on this group once we get our heads around how useful it is!

whereas a gg newbie like me has trouble just replying in the first place, i mean, i have to stop now because i had to spend a while figuring out touch focus required to scroll this reply and the post on safari desktop mode on the ipad :)

some things will semi-randomly catch fire and become popular, keep up the great work everyone!

until next time xx

[PMario]

On Friday, March 5, 2021 at 3:37:17 PM UTC+1 dieg...@gmail.com wrote:

Hi Diego,

To others, can someone help me understand why my posts often don't get many (if any) response?  The first time this was posted it also inspired almost no response. This time as well. This happens to several of my posts, so I'm curious as to my "disconnect" with the community somehow.

Your OP is very detailed and well written, which is good. On the other hand it will need some time to read it, and probably a lot more time to respond.

I did create the uni-link plugin, which you named several times in the OP. ... I think "some" of your requests may be possible with uni-link extensions and others may be easier using a new "concept", instead of linking. ... BUT ... I have to think about it.

Technically the link [[alias|?]] calls the <<aka ...>> macro. aka = also known as ..

I did already think about a syntax like this: [[alias name|!macro-name]] ... The problem with macro-calls is, that many of them need more than 1 parameters. ... So we need a way to call macros and give them enough additional information, that they can do something useful.

I do have a new plugin in the making, that may be able to solve this problem. eg: 『?:"alias-name":"relation type" text to be shown』

The aka macro call can already be detected as an "alias backlink", if the uni-link plugin is installed. ... So it should be possible to create "new relational" backlinks logic, that can be detected ...

So a combination of the new Custom Markup Plugin and the Uni-link plugin may solve several of the mentioned problems.

... But as I wrote, ... I need to think about it.

have fun!

mario

[PMario]

On Saturday, March 6, 2021 at 10:34:14 AM UTC+1 PMario wrote:

I did already think about a syntax like this: [[alias name|!macro-name]] ... The problem with macro-calls is, that many of them need more than 1 parameters. ... So we need a way to call macros and give them enough additional information, that they can do something useful.

I do have a new plugin in the making, that may be able to solve this problem. eg: 『?:"alias-name":"relation type" text to be shown』

@Diego,

What would you think about a syntax like this.

At the moment uni-link alias link looks like this: [[alias|?]] or [[alias|?fieldName]]  which is translated to: <<aka target:"alias">> or <<aka target:"alias" field:"fieldName">> which can be shortened to: <<aka "alias">> or <<aka "alias" "fieldName">>

The advantages of the macrocalls are, that they are easy to extend eg: <<aka "alias" type:"mention">> which would add a backlinkable "type" element. ... There needs to be some code, that can handle the "type" info.

A custom markup call could look like this:『?:"alias"』or 『?:"alias" fieldName』or with the "type" info added it could be: 『?:"alias":"type"』 ...

『?:"alias":"type" fieldName』could be translated to <<aka "alias" field:"fieldName" type:"type">> but I'm not really sure, if there is a big difference between this new syntax and a macro call.

just some thoughts
mario

[PMario]

On Wednesday, March 3, 2021 at 9:46:09 PM UTC+1 dieg...@gmail.com wrote:

The only missing feature (besides the autocomplete given by the EditComptext plugin) is specifying the relationship type.

I have no idea what syntax would "make the most sense" but I can propose some:

• relationshipType::[[ aliasName |? fieldNameToRender]] - like in Roam?
  
• [[ aliasName |? fieldNameToRender | relationshipType]]

I kind of like: relationshipType::[[aliasName|?fieldNameToRender]] .. but I think it's meant in a completely different way in Roam.

TW already has [img x="" y=""[tiddlerName]] for image and [ext[https://xxx]] for external link handling.  ... BUT ... those elements are "hardcoded". So they can only do 1 thing.

[type[alias|?]] would also have a "hardcoded" type element. eg: [mention[alias|?]] or [participiant[alias|?]]  ... I'm not really happy about the limited possibilities.

What do you ALL think?

-mario

[PMario]

On Wednesday, March 10, 2021 at 12:54:55 PM UTC+1 PMario wrote:

...

[type[alias|?]] would also have a "hardcoded" type element. eg: [mention[alias|?]] or [participiant[alias|?]]  ... I'm not really happy about the limited possibilities.

There is 1 more thing, which may be problematic. ... If we use this pattern [dynamic text[]] we will limit the possibility for future TW extensions, that would want to use the same pattern. So imo it would need to be something like: [? dynamic text[]]    where [? is the hardcoded part similar to [img [ext ..

just some thoughts.

-mario

[PMario]

On Wednesday, March 3, 2021 at 9:46:09 PM UTC+1 dieg...@gmail.com wrote:

...

Something that I think should be incorporated into the core (!!!!) (or at least with uni-link) is the Edit-Comptext dropdown plugin. This plugin already lets you define custom dropdown templates, so its natural to incorporate the filters uni-link provides. 

I did test the Edit-Comptext plugin and it seems to work nicely with uni-link, except, that it uses the same keyboard shortcut CTRL-SPACE by default. ... hmmm

First thing, that I could think of, is a link to the plugin in the uni-link documentation. May be I could add some example configs, that make sense for unilink eg:

{

  "pattern": "|?",

  "filter": "[all[aliases]]",

  "start": "[[",

  "end": "|?]]"

},

Second thing is, that comptext plugin should offer a possibility for other plugins to provide some config patterns as shown above. So if both plugins are installed, they would automagically be available after a page reload.

-mario

[Mark S.]

What does "relationship" bring to the table? How would it be useful? Are there some examples?

It feels like an unnecessary complexity, but maybe I'm missing something really neat.

On Wednesday, March 3, 2021 at 12:46:09 PM UTC-8 dieg...@gmail.com wrote:

[PMario]

On Wednesday, March 10, 2021 at 6:47:30 PM UTC+1 Mark S. wrote:

What does "relationship" bring to the table? How would it be useful? Are there some examples?

 

At the moment we use tags and fields to define connections between tiddlers.

It would also be possible to define some of this info within a link. eg: If you have [[Jack]], [[Joe]], [[Jill]] and [[Jane]] you may know they are persons because we have names here. But you don't know more ...

Let's say the tiddler named: Jack contains

title: Jack

[? stepson[Joe]], [? daughter[Jill]] and [? wife[Jane]]

Now we know a lot more, without the need to visit any of the other tiddlers. ... It's a patchwork family.

It feels like an unnecessary complexity, but maybe I'm missing something really neat.

With the right code the info above can be extracted, to eg create a family tree. .. The advantage is, that no fields or tags are used.

The tree can grow organically while the content is entered. eg: Joe may link to [? father[Stephen]] ... and so on. ..

That's only 1 example. The initial example in the OP was [? mention[mr A]]  and [? participant[mr J]] [? participant[mr K]]

The problem is: TW core doesn't support such information at the moment. ... BUT it's interesting to think about it.

-mario

[PMario]

On Thursday, March 11, 2021 at 2:14:38 PM UTC+1 PMario wrote:

title: Jack
[? stepson[Joe]], [? daughter[Jill]] and [? wife[Jane]]

Some technical background. At the moment TW builds the "backlink" information at "parsing time", when the parse-tree is created. Parsing the tiddler content is a very "heavy weight" function. .. It need quite some CPU cycles. ... That's why this info is cached and only recreated if a tiddler changes.

If someone uses the eg: backlinks[] operator, the TW core has to touch every tiddler and parse it. Then it internally searches the parse-tree for a pattern like:

"type": "link",

"attributes": {

  "to": {

      "type": "string",

      "value": "Joe"

  }

},

and it stores some info in the indexer. ... Since we have to "run" all this code already, it shouldn't be too much of a hassle to add additional info to the link structure. eg:

"type": "link",

"attributes": {

  "to": {

      "type": "string",

      "value": "Joe"

  },

  "relation": {

      "type": "string",

      "value": "stepson"

  }

},

In a second step, this info can be "indexed" and we can create filter operators for it.

-mario

[Soren Bjornstad]

I'm really liking the idea of piggybacking on the existing extended link syntax -- better than the versions I suggested off the top of my head in my original post. And thanks for the technical background.

On not wanting to put arbitrary text between the [['s: this seems like exactly the same issue that we have with filter operators/fields, so could we use the same solution? Have a hard-coded string ? or type or something that serves as an unambiguous syntax, and then people can choose to use that or not (this would also let them call a relationship, e.g., img). If they use the implicit form and someone else later comes along and overloads it to mean something else, then that's on them to go back and add the full format to disambiguate it.

Mark, for more on the use case, also see my post that Diego mentioned in the OP.

[PMario]

Hi,

Just thought about it. .. We will also need to make sure, that the "relink-plugin" can handle this new stuff

-mario

[Thomas Elmiger]

Hi,

I must admit, i am not able to see the advantage of storing information about a person or object in a link instead of in a field. In fields you can store

name: Joe

familiy: Doe

father: Alfred Doe

mother: Beatrix Doe

spouse: Foo Bar

course-about-hacking: attended

The last one might be solved differently by storing a list of attendants in a tiddler "course about hacking" of course. Now you could write macros to style links based on that information. And you would have all the information in the one place where it makes sense istead of scattered over many tiddlers and many links. – But let’s assume it makes sense in some contexts.

Question: how would HTML handle the additional relation information?  Could it be presented to users in a useful and accessible way?

And a short reminder: HTML anchors  (a) already can have type and rel attributes – both are not supported by the link widget at the moment, but there are indeed some kinds of relations already covered to be aware of. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a

 One last provocation: How about [[ Joe (stepson) | Joe Doe ]] ?

Goodnight ;–)
Thomas

[Soren Bjornstad]

Thomas,

I must admit, i am not able to see the advantage of storing information about a person or object in a link instead of in a field. In fields you can store 

name: Joe

familiy: Doe

father: Alfred Doe

mother: Beatrix Doe

spouse: Foo Bar

course-about-hacking: attended

Indeed, and in many cases that may well be a better approach. The primary benefit to relationships on the links, to me, is that if you want to have a clickable link in the text, you don't have to describe the relationship twice, once in the text and once in the field. Don't repeat yourself should apply to TiddlyWiki.

I appear to have been the one who originally sparked this discussion, and I have to admit I'm surprised how much interest it's gotten. :-) I wouldn't be terribly disappointed if nobody wanted it, because as you point out there are few major advantages to typed links over fields, but I do think it could be a marginal improvement in quite a few cases.

Question: how would HTML handle the additional relation information?  Could it be presented to users in a useful and accessible way?

This is a good point! Maybe a tooltip if there isn't already one on the link?

 

And a short reminder: HTML anchors  (a) already can have type and rel attributes – both are not supported by the link widget at the moment, but there are indeed some kinds of relations already covered to be aware of. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a

Interesting idea, but if I'm reading the Mozilla docs correctly, both these attributes have a specific set of standard values, so it wouldn't work for adding arbitrary relationships in TW.

 

 One last provocation: How about [[ Joe (stepson) | Joe Doe ]] ?

You can't introspect this using filters, at least not easily, which I think was the primary goal of this proposal.