Concept: tag intersection

#1

Hi, I’d like to share my recent idea. You can go directly to a demo I’ve set up.

download

The concept of tag intersection is (hopefully) useful to manage and explore relations between tiddlers and tags in situations where a clear tag hierarchy is not present and where using dedicated fields to describe “features” of tiddlers instead of tags is unwieldy.

The base of the concept is to treat tiddlers with a special title in the form of <tag1><separator><tag2> as intersection of two tags – e.g. in a wiki about various animals we could have a tiddler Flying%Swimming to refer to all tiddlers tagged both with Flying and Swimming.

With some view templates the following can be achieved:

  • in an intersection tiddler, also a missing one, see a list of all tiddlers tagged with both tags
  • in all tiddlers tagged with both tags from an existing intersection, see that the intersection exists
  • in any tiddler tagged with at least two tags, see a list of all possible missing intersections – these are not all meant to be “cast into existence”, since they are useful also as missing tiddlers

The demo linked above goes more into details on how I achieved it and shows how it works on a simple example wiki.

Some screenshots:

Links to an intersection displayed below a tiddler:

image
image708×282 8.35 KB

Links to other possible, missing intersections below a tiddler:

image
image707×437 23.8 KB

Links to tiddlers contained in a given intersection:

image
image705×390 11.9 KB

The whole thing feels a bit overcomplicated, but it has been helpful to me so far. It is certainly not as elegant as the tag hierarchy mechanism, but I intend to use it in less organized notes where such hierarchy is not easy to create and maintain.

I have to see how useful it is in long term, so I wouldn’t recommend it to anyone yet. I also don’t think it is universal enough to qualify to the tips&trick category here. In any case this has been an interesting exercise on using functions, even if I end up not using it in the future.

This could be added to the long list of examples of leveraging missing/virtual tiddlers here: Virtual tiddlers

@TW_Tones I think you might be interested in taking a look, you’re doing some advanced things to extend the functionality of tags.

5 Likes
Tag management in TW
#2

This is great stuff! I don’t have any immediate use for it, but it’s going into the list of tools I will have to remember, because there will be a day!

Listing of tiddlers in an intersection of three or more tags (title like Bird%Yellow%Herbivore) would be doable with similar approach, but I have yet to find a situation where it is needed, and handling all the other aspects and edge cases becomes increasingly difficult using just simple wikitext methods.

… and of course then you’re dealing with O(2^n) possibilities, not just O(n^2). That’s a little frightening.

One very minor suggestion: add a small amount of left and right padding around the separator in titles to increase readability:

\whitespace trim
<h2 class="tc-title" title="This is a tag intersection tiddler">
<$list filter="[<currentTiddler>split[%]]">
	<$list-join><span class="wilk-inter-title" style="padding: 0 .25em;">%</span></$list-join>
        <!--                        here ---->`------------------------'  -->
	<<currentTiddler>>
</$list>
</h2>

(probably better done with a class and un updated stylesheet, but this should show what I mean.)

A question: I see that the % is hardcoded throughout, but the discussion mentions other separators. Are you planning on parameterizing that?

A wish: I wish the intersection sign you use internally, ∩, was easier to type. That would make a fantastic separator!

#3

That’s a good idea! It looks much better with a little spacing.

I wasn’t planning so far, and I don’t see any better candidate characters in my case anyway:

  • ^ is the stupid waiting-for-second-keypress character on the German keyboard I got at work (like ~ on US keyboard),
  • easily-typable characters like &, *, |, @ are either in use somewhere by TW syntax (not that it would necessarily clash, but I don’t want things to get confusing) or have a bigger chance of being actually used in a title,
  • ∩ would of course look great, but I want it to be a character that’s easy to type on any device in any field, like search or command palette.

This should be quite easy to parametrize though, if I were ever to develop it further into something more polished. If I recall correctly, it is only used in filter operators where it could be introduced as a variable, like split, join, search.

#4

@vilc thanks for sharing an interesting idea, taking an innovative approach. Apart from tying two tiddlers together like this, you also suggest a view of the intersection, and making use of the knowledge of the intersections.

I do think we could make better use of relationships between tags, but also as a result the relationships between lists defined by those tags. Lists are sets, and we could move further into advanced set handling.

I need time to “digest your idea.”

#5

Very great tool, and I absolutely love the image of the two tags overlapping. Genius. Thanks for this tool!

1 Like
#6

I find @vilc’s idea interesting in a number of respects, and will return to it as many times as I need to follow various leads.

An interesting concept is the idea that the title contains within it information about how to display information related to it, the “title”.

I do think there are other ways to represent tag intersections and other tag relationships but combining it with displaying the result is great.

This also illustrates. How to set, then extract relationships from the wiki and present existing and proposed relationships.

1 Like
#7

A very interesting idea. Have to think about how I might use it in my particular archive wiki as there are obvious intersections with as many tags as I have already.

bobj

1 Like
#8

I love this idea.

Of course, folks could adapt this as needed. I would just use the ampersand (with spaces around it), myself. It may have other uses, but it’s easy to type, is perfectly legal within tiddler titles, and looks elegant.

One funny thing is that your demo — so far — doesn’t do anything with any tag’s missing “home” tiddler by itself. If typing Bird%Flying as a tiddler title gets me a template, surely this would be because we’re in a tiddly landscape where there’s a virtual tiddler that does something with a category tiddler title like Bird too. And presumably that template would point to which tag intersections (starting from this one) are actually occupied. But I get that this is proof of concept, and I love it.

2 Likes
#9

Exactly. I’m still not sure if it is the right approach for me, but I have not seen anything similar yet, so I thought I’d share it.

In the beginning of collecting my work-related notes I used a simple and “wide” tag tree approach, e.g.

Bird → (all birds)
Yellow → (all yellow animals)

It was easier like this when there were not many tiddlers to warrant a complex and “tall” tag tree approach, which would be:

Bird → Yellow Bird → (all yellow birds)
Yellow ↗

This is the way TW intended it to be, and has many neat advantages like being able to use toc macros. But, without kin filter plugin or some alternative, it is impossible to comfortably retrieve e.g. all birds or all yellow animals if the depth of the tree is unknown.

So, out of reluctance to reorganizing my tagging system and to becoming dependent on a plugin, I started exploring this tag intersection idea.

Right now, I’m actually think the “tall tag tree” + kin filter will be better for me, but it requires some work, and in the meantime I have the intersection thing.

Now that I think about it, I don’t know why I didn’t went for it. I don’t suppose I have any or ever will have many titles with &. This also solves the spacing problems, and I it should work my current code without issues.

#10

Even if you do, I don’t suppose it’s a problem. You just make your view template display only if what’s on at least one side of the title is a tag. (If it’s a wiki that tracks businesses, and Procter & Gamble is a tiddler, but there’s nothing tagged Procter (etc.) then the view template for the intersection just stays quiet and shows nothing…)

#11

Your eventual Barnes & Noble tiddler will mess it up forever… :slight_smile:

#12

Ah Springer you beat me to it…

#13

If course barnes&nobel is unlikely found in the wild and spacing could be used when not representing tags.

  • although the split and test methods need development
  • eg the above has no spaces but “Barnes & Nobel” does. One has capitals the other does not…
    I do favor bringing in unicode symbols and I have many ways to access them on my desktop, but it should be possible to make a picker in tiddlywiki.
  • a button to intersect two tags could also have the symbol encoded in it, so keyboard access is not needed.
1 Like
#14

I have done just now, it was quite straightforward. There is a config tiddler, whose text is the separator.

Using this improvement, I’ve changed the separator to " & ", as @Springer suggested. It looks good and makes the styling of the separator (spacing, subtler color) not necessary. I have left the class assigned to it just in case though.

Of course the titles have to be changed manually, Tiddler Commander comes to help. The Relink Titles configuration also has to be manually updated, unless it can contain a transclusion, I’m not sure.

The case of a title incidentally containing the separator is not covered yet.

1 Like
#15

Perhaps Split on & then test if first[] and last[] titles is[tag]?

#16

And then if they’re not both tags, add a “This is not an intersection” checkbox that adds a plug-in namespaced field to the tiddler that will prevent you trying in the future?

#17

That makes sense however such “intersection tiddlers” are a different type and I tend to categorise tiddlers as such, by setting an object-type fieldname. But I think the idea was for spontaneous intersection tiddlers.

It may not be such an issue if you first test if the title contains & and only do the longer test if so. It would only be a drag on performance (if at all) if you have a lot of intersections open at a time, and this may introduce other performance issues.

Side note:
I think testing a string contains another, that may look like a title, in a filter, may be a gap in the current filter operators for example you would think the following;

  • Use the contains operator - but this is about a title being in a list field
  • Use the search operator - filter the input by searching tiddler content
  • Use search-replace operator, this still acts on whole titles, its designed to replace not just find.
  • Sure regular expressions can help but It would be nice if it was useful to a larger audience.

This may be an opportunity for a new [sub] string test operator.

1 Like
#18

This is a very clever concept, @vilc! And I think Scott’s suggestion for suppressing false positives is a good one; it’d be easy to exclude tiddlers with a particular field.

Though personally, I might be inclined to let the view template appear on a “Barnes & Noble” tiddler if “Barnes” and “Noble” were both tags, even if it technically should not… If I had added both those tags in my wiki, then I might conceivably be looking for their intersection, and having the tabs there at the bottom of the tiddler wouldn’t hurt even if I were only looking for the bookstore.

How would this differ from [search:title:literal,casesensitive{!!title}] (other than, perhaps, brevity)? search:title does work on input strings, regardless of whether they’re also extant tiddlers.

#19

Yes, I overlooked this as mentioned Accessing the title passed into a function? - #3 by TW_Tones

But also consider rather than [search:title:literal,casesensitive{!!title}] having the operator [containing[string]] would still be an advantage.

#20

Very good.

Under the hood are REAL conceptual intersections.
AND their ontological remit.

Like Pre-Classic, Classic, Funky and Punk Funky.

Anything, any device, and any intersection, that can contextualise meaning is good!

How about FOUR PHASES already?

My point? Your EXPLICIT blending is good.

Just a comment
TT

1 Like