[meta] discussion of tags vs links / relations in TW.

[HC Haase]

This is inspired from my thread on tag picker slowdown and Dave's thread on bi-directional linking. From these discussions on the TW tech and user behaviour with relations, I think it could be useful to have a more fundamental discussion about relations (tags and links).

Different folks different strokes, is a good thing to remember when talking TW. I will do my best to remember that not all, do things the same way as I. But sometime I might forget.

I will approach this from my own point of view. This is not to say that this is the right way to do referencing, but is an attempt to get some clarity by starting at one point.

In terms of relations between tiddlers we have

1. tags: can be hierarchies as in the TOC, and more network oriented. It gives us categories
2. links: is a stronger relation that tags, it gives us a direct connection to another tiddler.
3. backlinks: are also links, but not as intentional as normal links, thus these could bring some emergence and show connection you forgot.
4. list
5. listed
6. searches (and bimlas forward linking thing)

I don't see list and listed as too relevant right now, so I will leave them out for now.

The way I see it tags and links are different. Links are more direct and intentional - a strong relation if you will. Tags are a broader categories (and/or hierarchical). This also means that tags become my primary mechanism for order and links get a more ad hoc use. I had the feeling that this is the way tags and links were designed/thought to be used (but I could be wrong).

So in summery

• tags
• hierarchy
• category/keyword
• primary sorter
• many out of the box features (toc macro, tagging filter, colour coding, drop-down picker)
• don't pollute the text space
  
• links
• stronger link
• more ad hoc
• secondary sorter
  
• not (out of the box) optimal for hierarchies
• may pollute the text space
  

Some people rely more on links instead of tags and some more on fields (other than tag). This puzzled me a bit. But if you make some lists that show nested list of links, to show hierarchy, you could use links for the same as tags (e.g. Dave's blink edition). SO maybe there are no real difference between tags and links? Can they be used interchangeable? and if so why not only have one method?

You link people;

• is there an advantage/disadvantage to using links for hierarchy?
• And how do you use links? do you have a "see also" section with keyword links?
• do you distinguish between "a link to another tiddler" and "child of tiddler link"?

Tags have many advantages that links do not have (out of the box) (toc macro,tagging filter, colour coding, drop-down picker). but if we strip them of these fancy cloths, are they any different than links?

Maybe I am rambling now.. I properly managed to confuse myself. I look forward to hearing your thoughts on this.

[bimlas]

HCHaase,

// advertising //

There is no big difference between links and tags in navigation. In fact, any field can contain tiddler titles like tags, so any field can be used as tags. This is how the Locator plugin works, it allows you to browse tiddler links like table of contents, or connect a tiddler to other tiddlers based on several different links.

https://bimlas.gitlab.io/tw5-locator/

// advertising ends //

Otherwise, I don't think links can really be used to build trees. If I have a tiddler on Javascript, I might mention TiddlyWiki as an example, but it doesn't really belong to the subject. I think that different fields can be more effective in defining the structure of data as some kind of "grouped tags". You can see an example on page https://bimlas.gitlab.io/tw5-locator/#TiddlyMap%20Activities%20example

Example: You can connect TiddlyMap, Tiddler Commander, etc. to TiddlyWiki via the "extension-of" field. Through the "tutorial-of" field, various descriptions can be linked to TiddlyWiki. TiddlyMap can also be linked to the "Mindmap" topic through the "example-of" field.

I don't quite know how to link tiddlers, but I think the different fields give context to the connection, a name that groups them together. If you only see a list of links, they are not organized, and the tags are also mixed (table of contents tags and hashtags), not grouped.

But with vanilla TiddlyWiki, I would use tags and links mixed: tags help me to structure notes, so if I am curious about a topic, I can find it quickly . Links, on the other hand, help to further explain the details, so I only need to place a link to the connecting concept so the user can see it if he is not already familiar with it. The link is like a footnote or a reference.

[bimlas]

Actually you can try to navigate by links:

* Install https://bimlas.gitlab.io/tw5-locator on TW.com, drop the Locator View on it as well
* Save and open
* On the top of HelloThere press the double arrow button to open in the sidebar, switch to Locator sidebar
* Press the gear icon to open context settings and switch the field of tree to LINKS-IN-TEXT
* Use the arrows near the list itens as you would in a regular ToC

[Mark S.]

It's not practicable to use long tag titles. It also complicates things to use spaces in tags.

It would be helpful if you could navigate the tags by keyboard, rather than by mouse. That is, that you could tab into the tag field and then use the up/down keys to locate your tag. It doesn't seem to even be possible to navigate INTO the tag drop down using arrow keys.

I suppose the real problem with tags is that they're displayed in a vertical list. If they were spread across a table, then it might be easier to use large numbers of them. Creating subsets of tags seems like the most practical approach to large numbers of tags. Of course, if you have a really good memory, then you'll be fine with just typing two or three letters to narrow the list. But you might find as you get older that that approach is not as friendly as it used to be.

If you try TiddlyBlink, you'll find that you can create a kind of tree using links.

Links do pollute the text space, but so do #hashtags. And it seems like everybody is good with that these days.

On Tuesday, February 11, 2020 at 5:24:19 AM UTC-8, HC Haase wrote:

This is inspired from my threat on tag picker slowdown and Dave's threat on bi-directional linking. From these discussions on the TW tech and user behaviour with relations, I think it could be useful to have a more fundamental discussion about relations (tags and links).

[David Gifford]

Here are my two cents worth:

My understanding is that tags slow TiddlyWiki down faster than links if you want to tag everything and create a giant hierarchy. That would be a good topic for discussion to clarify if that is the case or not. Part of the slowdown, if I am understanding correctly, is the elaborate CSS of tag pills and dropdowns for each one, and the often convoluted list filters we use for listing tiddlers by tag. But then perhaps links slow it down just as much. I don't know, but TiddlyBlink is in part to avoid tagging as much as possible.

Links are arguably faster to add to a tiddler than tags are. They can be done while in the act of writing the tiddler without stopping to go to a different field, dig through a list of tags, and and select one or create a new one. TiddlyBlink even speeds this up with the autocomplete for links (snowgoon's plugin), and automatic creation of tiddlers upon linking, and backlinks accessible from all tiddlers.

Links are better for sideways and one-level-up connections. Tags are better for multi-level tables of contents.

As Mark noted, long tags are terrible.

Note to Mark: Try the following in your Stylesheet to overcome the vertical list of tags problem:

```

/*TAG EDITOR AND DROPDOWNS*/

html body.tc-body .tc-block-dropdown-wrapper {width:800px;color:#2200bb;}
html body.tc-body .tc-block-dropdown {width:800px;white-space:normal;color:#2200bb;}
html body.tc-body .tc-block-dropdown a {display: inline-block;color:#2200bb;}
html body.tc-body .tc-block-dropdown svg {height: 1.2em;fill:#ccc;display:inline;color:#2200bb;}

/*TAG LABELS*/

html body.tc-body .tc-tag-label {font-family: 'Arial'; font-size:10pt; color:#2200bb;background-color:#eee;margin-bottom:6px;font-weight: bold;}
html body.tc-body .tc-menu-list-item {font-weight: bold; color:#2200bb;}

```

Also, see my cheeky comment below:

On Tuesday, February 11, 2020 at 7:24:19 AM UTC-6, HC Haase wrote:

This is inspired from my threat on tag picker slowdown and Dave's threat on bi-directional linking. From these discussions on the TW tech and user behaviour with relations, I think it could be useful to have a more fundamental discussion about relations (tags and links).

= thread. :-) While TiddlyBlink may be a great tool, I hope I am not threatening TiddlyWiki in any way with bi-directional linking! :-)

[Mark S.]

On Tuesday, February 11, 2020 at 8:38:47 AM UTC-8, David Gifford wrote:

My understanding is that tags slow TiddlyWiki down faster than links if you want to tag everything and create a giant hierarchy. That would be a good topic for discussion to clarify if that is the case or not. Part of the slowdown, if I am understanding correctly, is the elaborate CSS of tag pills and dropdowns for each one, and the often convoluted list filters we use for listing tiddlers by tag. But then perhaps links slow it down just as much. I don't know, but TiddlyBlink is in part to avoid tagging as much as possible.

I hadn't heard about CSS slowing tags down. When I tried to make a TW with 37000 vocabulary entries, it slowed to a standstill because the tag operator apparently isn't optimized for large numbers of tagged tiddlers. It turned out to be faster to do a search in the tag list field, which is surprising.

 

Note to Mark: Try the following in your Stylesheet to overcome the vertical list of tags problem:

```

/*TAG EDITOR AND DROPDOWNS*/

html body.tc-body .tc-block-dropdown-wrapper {width:800px;color:#2200bb;}
html body.tc-body .tc-block-dropdown {width:800px;white-space:normal;color:#2200bb;}
html body.tc-body .tc-block-dropdown a {display: inline-block;color:#2200bb;}
html body.tc-body .tc-block-dropdown svg {height: 1.2em;fill:#ccc;display:inline;color:#2200bb;}

/*TAG LABELS*/

html body.tc-body .tc-tag-label {font-family: 'Arial'; font-size:10pt; color:#2200bb;background-color:#eee;margin-bottom:6px;font-weight: bold;}
html body.tc-body .tc-menu-list-item {font-weight: bold; color:#2200bb;}

```

Thanks for that! Now that I've seen it in action, I'm not sure it's an improvement. Back to tag subsets.

 

[TonyM]

HC,

I would just make a couple of points - 

Titles, in camel case or [[square brackets]] are fully operational links as you know, to just a title is enough to have a link. Recently auto linking tiddler titles found in text was discussed and implemented. This allows auto linking. So any field like tags can hold one or more titles and each of these can automatically be a link.

I would suggest trying to keep the linking focused around tiddler titles.

Have you seen marios parent TOC, called TOCP? which sets up a hierarchy based on the parent field rather than tags. It has a new here (with Parent) You can do the same thing with any field.

Tiddlywiki has the features that you can build any network or hierarchy you want, in fact multiple hierarchies at the same time. I am trying to find a single relationship model tiddlywiki can not represent and have not yet. This includes maintaining "referential integrity" using out of the box tags, or building your own. This allows a change in one node without it loosing its relationships.

I hope this contributes to your thoughts on this issue.

Regards

Tony

[TiddlyTweeter]

Just a footnote.

On wider net, "tags" emerged as an alternative to "ranked categories".

The point was to escape hierarchical placements with a cross-cutting labeling system.

Its interesting that TW frequently revisits this issue in many forms weekly :).

A lot of TOC type things are reconstructing via tags what basic naming might do better! Its an issue about "state of knowing" as much as "technique of fulfillment".

IMO, and my interest, is really HOW to you combine "emergent knowledge" (tags good for that!) with "a nice logical user experience" (TOC good for that IF...)

Thoughts

TT

[PMario]

On Tuesday, February 11, 2020 at 6:16:09 PM UTC+1, Mark S. wrote:

On Tuesday, February 11, 2020 at 8:38:47 AM UTC-8, David Gifford wrote:

My understanding is that tags slow TiddlyWiki down faster than links if you want to tag everything and create a giant hierarchy. That would be a good topic for discussion to clarify if that is the case or not. Part of the slowdown, if I am understanding correctly, is the elaborate CSS of tag pills and dropdowns for each one,

That shouldn't be the case. Applying CSS is done by the browser and is highly optimized, in a way that most of the CSS settings are thrown away, because they are not active at the moment. ... There are some CSS styles eg: dropshadows, that are known to be expensive, but they would need to be applied to every element, which isn't the case for tag lists. 

The number of elements that have to be drawn is something that can slow down displaying a list of all tags.

eg:

 - tiddlywiky.com has about 2000 shadow tiddlers.

 - Listing them as links in AdvancedSearch on my PC needs about 600ms

 - 1 link is "built" using 2 DOM elements.

 - So the browser has to draw 4000 elements and apply the styling.

 - tiddlywiki.com has about 300 tags.

 - listing them in Advanced search needs about 100ms

   - 1 link is built the same way as above

 - listing them in the tag-dropdown needs about 500ms

   - 1 link in the dropdown uses 4 DOM elements

   - 1 link with an icons uses much more DOM elements.

 - We do have 1200+ elements that have to be draw + The much more complicated calculation of a tag-pill element.

   - tag-pill can be found at: core/macros/tag

The combination of the tag-pill element and the resulting DOM elements, that the browser has to draw, have the potential to make the tag-picker slow.

 

and the often convoluted list filters we use for listing tiddlers by tag.

That's right. Filters are a possibility where lists can be optimized. ...

 

But then perhaps links slow it down just as much. I don't know, but TiddlyBlink is in part to avoid tagging as much as possible.

The work, the core has to do searching for tags is probably the same as searching for links. 

On Tuesday, February 11, 2020 at 6:16:09 PM UTC+1, Mark S. wrote:

I hadn't heard about CSS slowing tags down.

That shouldn't be the case. see info above.

 

When I tried to make a TW with 37000 vocabulary entries, it slowed to a standstill because the tag operator apparently isn't optimized for large numbers of tagged tiddlers. It turned out to be faster to do a search in the tag list field, which is surprising.

It would be interesting to know the filter strings you used and how the tiddler / tag structure looked like.

Latest TWs have a $tw.perf.log() function, which can give detailed info, in the dev-tools if performance-instrumentation is enabled. ...

-mario

[PMario]

I'm replying to the technical part about links here.

On Tuesday, February 11, 2020 at 2:24:19 PM UTC+1, HC Haase wrote:

In terms of relations between tiddlers we have

1. tags: can be hierarchies as in the TOC, and more network oriented. It gives us categories
2. links: is a stronger relation that tags, it gives us a direct connection to another tiddler.
3. backlinks: are also links, but not as intentional as normal links, thus these could bring some emergence and show connection you forgot.

Backlinks, Missing and Orphan links are "synthetic" links. They have to be calculated, whenever they are shown. eg: To find backlinks every tiddler has to be loaded and parsed to calculate the "links", which the tiddler contains.

Internally the links are cached, so the parsing needs to be done only once. But showing a backlink using the cached "links" still needs to touch every tiddler in the store.

1. list
2. listed
3. searches (and bimlas forward linking thing)

list, listed and search will also touch every tiddler in the store.

-mario

[David Gifford]

Thank you, PMario, for your expertise, in this post and the previous one.

Question: given what you wrote in these posts, what will slow down TiddlyWiki faster: tagging or backlinking?

[Mark S.]

On Thursday, February 13, 2020 at 8:08:07 AM UTC-8, PMario wrote:

That shouldn't be the case. see info above.

 

When I tried to make a TW with 37000 vocabulary entries, it slowed to a standstill because the tag operator apparently isn't optimized for large numbers of tagged tiddlers. It turned out to be faster to do a search in the tag list field, which is surprising.

It would be interesting to know the filter strings you used and how the tiddler / tag structure looked like.

Latest TWs have a $tw.perf.log() function, which can give detailed info, in the dev-tools if performance-instrumentation is enabled. ...

-mario

It wasn't something convoluted, if that's what you're getting at. It was a simple tag[xxx] functionality that slowed to a crawl when there were thousands of tiddlers tagged. Replacing the tag operator with a search operator improved performance. There's no real hierarchy -- just a handful of tags to indicate that a tiddler is word, and what kind of functionality it has (adverb, verb, etc.)  It was surprising that the tag operator performed so poorly. It's not something that I want to recreate. I now have 72000 entries, and get reasonable performance on a tablet -- but I don't use the tag operator.

 

[PMario]

On Thursday, February 13, 2020 at 5:50:22 PM UTC+1, Mark S. wrote:

On Thursday, February 13, 2020 at 8:08:07 AM UTC-8, PMario wrote:

That shouldn't be the case. see info above.

 

When I tried to make a TW with 37000 vocabulary entries, it slowed to a standstill because the tag operator apparently isn't optimized for large numbers of tagged tiddlers. It turned out to be faster to do a search in the tag list field, which is surprising.

It would be interesting to know the filter strings you used and how the tiddler / tag structure looked like.

Latest TWs have a $tw.perf.log() function, which can give detailed info, in the dev-tools if performance-instrumentation is enabled. ...

-mario

It wasn't something convoluted, if that's what you're getting at.

No. I was just interested in the structure.

 

It was a simple tag[xxx] functionality that slowed to a crawl when there were thousands of tiddlers tagged. Replacing the tag operator with a search operator improved performance. There's no real hierarchy -- just a handful of tags to indicate that a tiddler is word, and what kind of functionality it has (adverb, verb, etc.)  It was surprising that the tag operator performed so poorly.

Yes, and it would be interesting why.

 

It's not something that I want to recreate. I now have 72000 entries, and get reasonable performance on a tablet -- but I don't use the tag operator.

So you have about 72k tiddlers and most of them are tagged: word ... right?

The set of words is equally typed with parts of speech ... ?? ... So may be 20% 20% 15% 15% 10% 10% 5% 5% of tiddlers are tagged different?

Does the tiddler text contain links?

Would this be a schema, which I could do some tests?

-mario

[Mark S.]

Hi PMario,

The original topic was here:

  https://groups.google.com/forum/#!msg/tiddlywiki/U1ZKK8UIk94/Ee0LGEZiBAAJ

You posted to it as well. Jed made some comments that explained why it was happening.

I think this is fairly close to up-to-date:

  https://marxsal.github.io/EODICT/EO-DICT.html

Sorry, there's ONLY 63000 entries.

The tag operator works fine on things for which there aren't a lot of tags (like saved filters).

To see how it runs the old way, you would want to change

   "[contains:tags<listfilter-role>] ...

to something like tag<listfilter-role> . There may be more than one place to change.

There was also template code in WordTemplate that now has:

  <$list filter="[all[current]has[en]]">

But I'm pretty sure it originally had

  <$list filter="[all[current]tag[Vorto]]">

Thanks!

[HC Haase]

So many exciting things happening on this forum, so little time.

@david

>Links are better for sideways and one-level-up connections. Tags are better for multi-level tables of contents.

Yes that is why i use tags and links as i do. Tags are good for multi-level toc (as alo noted by @tiddlytweeter), but would it not be possible to use links for that also? Isn't that what you are doing David with blink?

If not. Are you maybe no so interested in multi-level toc?

>As Mark noted, long tags are terrible.

Why? Many of my tags have space in them, and some are sentences long but i dont see the problem with that. I just seach for them and select. A d why would a long link be better?

And I hope my poor spelling isn't a threat to the discussion in this thread :)

[David Gifford]

Yes that is why i use tags and links as i do. Tags are good for multi-level toc (as alo noted by @tiddlytweeter), but would it not be possible to use links for that also? Isn't that what you are doing David with blink?

If not. Are you maybe no so interested in multi-level toc?

I use an outliner (Dynalist) for toc's, or do them by hand if in TiddlyWiki. For TiddlyBlink I was more interested in seeing how linking and backlinking would help me jump back and forth between related tiddlers: a book, a note, a topic, a similar topic, a topic I would not have assumed would be related, etc.

[HC Haase]

@tiddlytweet

>Just a footnote.

>On wider net, "tags" emerged as an alternative to "ranked categories".

>The point was to escape hierarchical placements with a cross-cutting labeling system.

>Its interesting that TW frequently revisits this issue in many forms weekly :).

>A lot of TOC type things are reconstructing via tags what basic naming might do better! Its an issue about "state of knowing" as much as "technique of fulfillment".

How would basic naming be better? Can you give an example?

Please elaborate on the state of knowing" as much as "technique of fulfillment" thing.

>IMO, and my interest, is really HOW to you combine "emergent knowledge" (tags good for that!) with "a nice logical user experience" (TOC good for that IF...)

Yes i agree. I am thinking that tags and links maybe could be collapsed to one thing to make connections and emergent knowledge structures more vissible.