In-text semantic annotation of links

[ybabel]

Right now, nodes are created from Tiddlers. That's great.
Edges are also created from Tiddler : tmap:link (eq Manual link) and tmap:tag (eg Tag)
If I'm not mistaken, that's pretty all we can do from tiddler's content.

In my use case, I'm more interested in automatic graph creation from tiddlers content than drawing edges in the graph editor. It's because I want TiddlyMap to help me visualize, formalize, and understand my ideas structures (ex : determine which tiddlers are more central in my MindMap).

And ideas evoles and change often. It would not be practical to maintain my edges separately from text.

So, I'm thinking of a way to enrich automatic edges creation.

Maybe we can use the enriched existing syntax : [[Displayed Link Title|Tiddler Title]]
but, to be practical, it would mean adding a regexp in the 'Displayed Link Title' to extract an edge-type
something like [[demo:uses@Displayed Link Title|Tiddler Title]] or [[demo:uses->Displayed Link Title|Tiddler Title]]

and what about if we want to create a link in reverse order ? How could we say "create a tmap:link not "to" but "from" this Tiddler ?

maybe we can hack external linking ?
[ext[Open file|../README.md]]

something like : [tmap:"demo:uses"[Displayed Link Title|Tiddler Title]]
I don't know how feasible it is. I just know that right now, this syntax is not supported : it means that it would not degrade well if we remove TiddlyMap plugin.

Another approch would be to use a "surrounding syntax" :
{{tmap:"demo:uses"[[Displayed Link Title|Tiddler Title]]}}
or [[Displayed Link Title|Tiddler Title]]->tmap:"demo:uses" (which would be easy to type and understand)

Maybe I'm the only one interested in such feature.
I tried to figure out myself how to do it, but it's beyond my reach for now.

[felixhayashi]

Hi @ybabel

It would not be practical to maintain my edges separately from text.
Maybe we can use the enriched existing syntax : [[Displayed Link Title|Tiddler Title]]

Unfortunately, Tiddlywiki does not pass me the display-text when i use getLinks to retrieve all the links in the text. Otherwise I could easily use "Displayed Link Title" as link caption in the graph. I'll create an issue for this at the tiddlywiki repo.

it would mean adding a regexp in the 'Displayed Link Title' to extract an edge-type
something like [[demo:uses@Displayed Link Title|Tiddler Title]] or [[demo:uses->Displayed Link Title|Tiddler Title]]

Yes we would need to prefix it so TiddlyMap knows that it should use the display name as caption.

and what about if we want to create a link in reverse order ? How could we say "create a tmap:link not "to" but "from" this Tiddler ?

Maybe it is possible but this is really an edge case. In this case I recommend you go to the link source tiddler and add the link there.

Something like : [tmap:"demo:uses"[Displayed Link Title|Tiddler Title]]
I don't know how feasible it is. I just know that right now, this syntax is not supported : it means that it would not degrade well if we remove TiddlyMap plugin.

This is not possible. It would conflict with Tiddlywiki syntax.

In summary I can say the following:

I hope I can support using the display-title of a link in the future if Tiddlywiki allows me to. The other cases are really hard to support. Parsing of wikitext is complicated and would use many resources.

There is a widget that is not official (and not stable!) at the moment called $tmap-connections. Maybe it is useful for you but it will certainly change its syntax I do not recommend using it.

Anyhow. If you put this into your tiddler's body, you can display all in and out connections (to the current tiddler) in your text. For example:

    hjsh fjkshfj fdjgh jdfhgj dfjkgh dfg
    jgkfdjgkl fdgkj dgklj dlkfgj kldjg  fg hfgh fh 
    <$tmap-connections>
      <ul>
          <li>Edge id: <<edge.id>>(<<edge.label>>)</li> 
          <li>From: <<edge.from>></li> 
          <li>Role: <<role>></li> 
          <li>Neighbour: <<neighbour>></li> 
      </ul>
    </$tmap-connections>
    hjsh fjkshfj fdjgh jdfhgj dfjkgh dfg
    jgkfdjgkl fdgkj dgklj dlkfgj kldjg  fg hfgh fh 

The widget comes with the tiddlymap plugin.

-Felix

[ybabel]

Otherwise I could easily use "Displayed Link Title" as link caption in the graph. I'll create an issue for this at the tiddlywiki repo.

did you ? I didn't manage to find it.

[felixhayashi]

@ybabel here you go: #1749

[tobibeer]

Fwiw, rather than modify the TiddlyWiki link syntax, one could maybe amend it in a gracefully degrading manner, e.g:

• [[title|tiddler]](tmap>depends on)
• [[title|tiddler]](tmap<depends on) ...for the reverse direction
  • [[title|tiddler]](tmap>is dependency of) ...not sure, do you do that?

[ybabel]

I think it's not so different than the syntax I proposed : [[Displayed Link Title|Tiddler Title]]->tmap:"demo:uses"
but whatever, I don't mind ;-)
+1

[tobibeer]

@ybabel, overlooked that, didn't get all the way to the bottom of your post ^_^

[felixhayashi]

I am not against this but Jeremy will not support adding the link alias to the return value for getTiddlerLinks() (Jermolene/TiddlyWiki5#1749).

He said:

To compute the link text requires walking through the parse tree nodes and concatenating the text. getTiddlerLinks() is highly performance sensitive, because it's called many times to compute missing and orphan links, so we don't want to make it any slower.

Yet, he is not against creating a new function that does this parsing.

It would make more sense to make a new method that did the additional processing. You could look at the existing getTiddlerLinks() code as a starting point.

So if anyone wants to write a utils method that has the signature getTiddlerLinksAndType(tiddler) and returns an Array of objects where each object has the properties (1) linked tiddler (2) edge-type (e.g. "dependency of") and maybe also (3) link alias (but 3 is not really needed by tiddlymap), I would include it in tiddlymap, but I have no time at the moment to write that function. Also it will surely slow down tiddlymap, as Jeremy said, because it will add much additional parsing – so in any case I would make this feature optional.

-Felix

[ybabel]

I looked into the get TiddlerLinks code ... not really obvious to understand what's going on here.
Does this means adding a wikiparser rules based on the model of : $:/core/modules/parsers/wikiparser/rules/syslink.js ???

[tobibeer]

I don't quite get Jeremy's objection. To me, it just seems to require a barely extended regexp and the case where round brackets follow square brackets should have been rare in the past, if not nonexistent, i.e. [[foo|bar]](baz...and-then-some).

[felixhayashi]

I looked into the get TiddlerLinks code ... not really obvious to understand what's going on here.

I know. It is using caching to optimize performance and it travels down the parse tree to look for "link" nodes. then it stores all the "to" values in an array.

Does this means adding a wikiparser rules based on the model of : $:/core/modules/parsers/wikiparser/rules/syslink.js

Quite close, it is rather: https://github.com/Jermolene/TiddlyWiki5/blob/f8027a37080c06bc4ee02295a6dbe4a997417b2b/core/modules/parsers/wikiparser/rules/prettylink.js

And you would need to change the regex so it also looks at the round brackets and stores the value as "edgetype" in the parseTreeNode.

Once this is done, you would need to create getLinks and getBacklinks functions similar to the ones that exist at the moment but with the return values I described above: #119 (comment).

In summary: A bit difficult…

I don't quite get Jeremy's objection.

You are right, but I also understand that it is not directly needed for TiddlyWiki and would only make sense in combination with the TiddlyMap plugin so I guess that's the reason jeremy doesn't want to add it in the core.

[tobibeer]

You are right, but I also understand that it is not directly needed for TiddlyWiki and would only make sense in combination with the TiddlyMap plugin so I guess that's the reason jeremy doesn't want to add it in the core.

Not exactly true. The same syntax could be useful for a number of plugins that wish to leverage semantically qualified links as opposed to simplistic ones that won't tell me what the link means. I would even have this abstracted in a way that it isn't at all specific to tmap but rather a generic qualification of semantic link-relations... that will be used by pro users and should barely impinge performance for everyone else.

Could simply be...

[[pretty-title|tiddler-title]](qualifier|qualifier|qualifier)

[felixhayashi]

Not exactly true. The same syntax could be useful for a number of plugins that wish to leverage semantically qualified links as opposed to simplistic ones that won't tell me what the link means.

Hmm, yes, if you put it that way, I agree with you, it would make sense for all plugins that want to make sense of this additional information.

I would even have this abstracted in a way that it isn't at all specific to tmap but rather a generic qualification of semantic link-relations

Also good point.

[Jermolene]

Just to be clear, my objection was to the specific proposal that @felixhayashi originally made to change getTiddlerLinks(). As I explained elsewhere, it would radically change the behaviour of the function from just parsing the target tiddler to instead fully rendering it. There's a big performance implication, and a behaviour change that is not backwards compatible. That's the only thing I'm objecting to!

Anyhow, I quite like the idea of extending the pretty link syntax with a qualifier. I'm not so keen on the way that the proposal here resembles the Markdown link syntax.

There are also questions about how the additional link qualifiers would be implemented at the widget layer, for instance how they might contribute to navigation.

By the way @felixhayashi & @tobibeer: if you mention me as @Jermolene then I'll be more likely to see the discussion.

[tobibeer]

mention

Oddly enough, that has not yet made it to my writing habits too much. Will consider that more often.

[felixhayashi]

Hi @Jermolene

By the way @felixhayashi & @tobibeer: if you mention me as @Jermolene then I'll be more likely to see the discussion.

I actually did not mention you on purpose because this discussion was up until now rather TiddlyMap specific and I do not want to take your time away by including you in discussions that do not directly relate to TiddlyWiki.

Just to be clear, my objection was to the specific proposal that @felixhayashi originally made to change getTiddlerLinks().

Yes, I understand this and I agree that if this got added, it should be a separate function.

Anyhow, I quite like the idea of extending the pretty link syntax with a qualifier.

I now also started to think that such an enhancement makes sense in general, not only for TiddlyMap purposes, since it gives the user a chance to tell more about the type of the link that was added (as @tobibeer argued above), similar to the semantic web.

I'm not so keen on the way that the proposal here resembles the Markdown link syntax.

I think the suggested syntax was just an example how it could be done, not a final proposal. I agree that the user should not be confused by similar looking syntaxes.

-Felix

[tobibeer]

I think the suggested syntax was just an example how it could be done, not a final proposal. I agree that the user should not be confused by similar looking syntaxes.

👍

[felixhayashi]

Since we agree that this should make it somehow into TW as it serves a general purpose, I created this issue: Jermolene/TiddlyWiki5#2144

-Felix

[gloryVine]

Having the ability to give names to the links TiddlyMap generates automatically from text in the live view would be really great. Any updates on this?