Concept: tag intersection

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

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.

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…)

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

Ah Springer you beat me to it…

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

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

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

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?

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

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.

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.

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

Triggered by your post, I wondered what would happen if the “virtual” tiddler titles were directly treated as filter syntax.

This is probably a really bad idea, but I toyed around with it and on the surface, at least, it works. I was actually very surprised since these virtual tiddler titles contain square brace characters. That goes counter to the warning you see when creating a new tiddler with a title containing | [ ] { } characters.

Put the following in a tiddlers on tiddlywiki.com and add the tag: $:/tags/ViewTemplate

<$let titleAsFilter=<<currentTiddler>>>
<$list filter="[subfilter<titleAsFilter>count[]compare:integer:gt[1]]" variable=ignore>
<$transclude $variable=timeline limit=30 subfilter="subfilter<titleAsFilter>"/>
</$list>
</$let>

Then put this in another tiddler:

* <$link to="[tag[Macros]]"/>
* <$link to="[tag[Macros]] [tag[Filter Operators]]"/>

When you click on those links, virtual tiddlers will be displayed in the story river with a timeline view of the tiddlers which match the filter.

There are probably dragons lurking here. Don’t use it in any wiki you care about.

1 Like

Very interesting @btheado,

With such little code you enable the display of “titles that are filters”.

  • It once again throws up in the air “what is a title”?
  • It also shows how much more can be done with “missing tiddlers”
  • The resulting recent list could be just one of multiple selectable views, although I find “recent” is one of the most common lists I make use of.

This is certainly another source of “creative inspiration” that leads one’s minds to explore other possibilities.

  • What if such tiddlers (missing filter titles) could not be made into real tiddlers.
  • One thought is to make a system namespace beginning with [

I won’t detail it here, but this has inspired me to new ideas about “real virtual tiddlers” :nerd_face: . I must find an existing topic or start a new one to discuss this.

I now the concept of virtual tiddlers has become popular recently, but I am, still tempted to call these missing tiddlers, because if you create them, they “kinda lose their virtual status”. However in your example they retain their recent list.

  • I think one of the main reasons is if you do use such characters in titles it gets tricky referring to such tiddlers elsewhere, especially with [ ] and { } which are part of links and transclusion, that is, where does the title name begin or end?
  • However with careful use of TiddlyWiki script they can still be used, in some cases.

Very interesting idea. I have a similar and more complex user case which might be interesting.

Data structure

  • Tag bibtex-entry for all literature managed by refnotes plugins
  • Tag Domain for a specific research domain with a network like structure with multiple Ancestors and Descendants.

For example,

Domain Growth Stage

Domain Canola

image

  • Tag Doc for a document tagged with multiple Domains (e.g. Growth Stage and Canola).

Filtering

In each Domain, I list all literature which are tagged with this Domain or their Descendants (i.e. Growth Stage with either tag, (Growth Stage or BBCH Scale or Zadoks Growth Scale)).

In each Doc, I list all literature which are listed in all Domains (i.e. literature with tag [(Canola or Triazine Tolerant Canola) and (Growth Stage or BBCH Scale or Zadoks Growth Scale).

I had this idea too, but I thought I wouldn’t need it that often. When I keep going back to the results of a given filter, I usually put <<list-links>> macro with this filter in a tiddler with a human-readable and writable title.
But of course this is a very intriguing idea, as all other ways of conveying some information in the title itself.

Fascinating. I feel as though I’ve gone looking for this functionality before, although I can’t quite recall where. I don’t know if it’s a “really bad idea”, but it’s certainly intriguing.

Well, as long as you don’t create these tiddlers, the funky title strings are not a problem.

My quick variant is:

<$list filter="[<currentTiddler>is[missing]]"> 

<!-- OUTER LIST GETS THIS OUT OF THE WAY FOR REAL TIDDLERS, which should not have filter-like names anyway! -->

 <$let titleAsFilter=<<currentTiddler>>>

 <$list filter="[subfilter<titleAsFilter>!sort[modified]limit[10]]"/>

</$let>

</$list>

I may well add an “open all these” button — So this ends up functioning much like the filter-pill tool developed by @TW_Tones

1 Like

Note how @btheado’s solution tests if it is in fact acting as a subfilter.

But yes I thought this may get your attention :nerd_face: from this perspective