Bimlas,
With related thinking I think because we have links and tags we sometime
forget any standard implemented text can subsequently be searched and at a
minimum list tiddler containing that string eg §Pasta #pasta whether that
string is a link, backlink or "naked". With the search highlighter and
freelinks plugins this is enhanced even further.
I am currently working on a tool called "advanced search indicators". It
monitors the search string entered and responds according to a range of
facts about the search string, like if it detects a system tiddler exists
it lets you open them with a click, if it is also a tag it provides a tag
pill to review it's members, View/edit, clone, open in new window and a lot
more become one click away. basically to make a lot of things come alive
for tiddlywiki it all *depends on what is searchable*.
My only piece to finish it is to determine if the search string is a prefix
or a suffix to tiddlers to provide a click to list tiddlers so
prefixed/suffixed, so almost finished. Although I am trying to automate the
generation of a demo site for each of my project(s).
It would be easy to detect the search string starting with # and thus
search for "hash tags", a view template that lists and links any hashtags
found in a tiddler and more would extend hash tagging functionality. With
my search indicator solution you don't need to touch the standard and
advanced search mechanisms. This will allow you to choose [[#tagname]]
#tagname #[[tagname even !#[[tagname]] and other forms (`<<# tagname>>
{{||tagname}}` so as an author you can ask how you want that hash tag
treated. This is the advantage of coding a solution once removed from the
standard and advanced search process. this is all about the conventions you
use and the tools that help implement them.
By the way how do you enter § from the keyboard?
In closing the relink plugin now makes a big difference to this kind of
text convention because you can keep such strings up to date on changes.
The sky is not even the limit in tiddlywiki.
Regards
Tones
On Friday, 21 August 2020 22:07:49 UTC+10, bimlas wrote:
>
> Sorry to fill this thread with my ideas, but I feel like they fit the
> title of the topic.
>
> I think on the one hand I understood how the concept of "hashtag" came
> into being, on the other hand I found a (I think) better use for it.
>
> I want to group the recipes to see their properties in a list, e.g. that
> if I look at the list of pasta foods, I want to know if that food also
> contains sour cream.
>
> The advantage of tags and fields is that you can easily group notes with
> them, so it's easy to filter recipes by ingredients field (this can
> include, for example, "cheese" and "pasta"). Notes can be grouped
> dynamically (although I am against the paper-based Zettelkasten), so I can
> create a view where foods are grouped by main ingredient (pasta dishes) and
> can be converted at the touch of a button to be grouped by additive (cheese
> dishes) .
>
> Thinking of Index notes and Link-based navigation, this is harder to
> accomplish than with fields: if I want to link to pizza, the pasta note
> index note should have a "cheese dishes" category, and the cheese food
> index should have a "pasta dishes" category to easily I can find it no
> matter where I start my search. This information is a duplication because
> we are talking about the same food (pizza), but depending on the view, I
> categorize it into several categories (in both cases it is the "cheese" and
> "pasta" categories, only the "parent category" is different). The solution
> is to have only one topic in an index without subcategories: pasta dishes
> should be just a simple list, there should be no "cheese" category in it,
> just as there should be no "pasta" category in cheese dishes. If I want to
> know about pasta dishes with cheese, I can only get it by query.
>
> One solution is for a note about a particular food (pizza) to link to the
> "properties" that are true to it (for "Cheese" and "Pasta" notes), so index
> notes are built based on backlinks, you don't have to list yourself them in
> each related index. This way I can find out which note has a link to both:
> I can either use the "[[Pasta]backlinks[]] ..." filter, or if the note
> title is like an API method
> <https://notes.andymatuschak.org/Evergreen%20note%20titles%20are%20like%20APIs>,
>
> just "[[Pasta]] [[Cheese]]" text.
>
> The problem with this is that I don’t want to disfigure useful backlinks
> with links that only use the ingredient at the mention level (any cheese
> dish would link to the “Cheese” note, though only to indicate that this
> ingredient needs to be added as well, but the note is not really about the
> cheese itself). In this respect, it would be worthwhile to create "property
> notes" that would only be used in this respect, e.g. "§Cheese" and
> "§Pasta": their backlinks are guaranteed to contain only notes that "use"
> that property.
>
> If I guess correctly, I now understood how the concept of the hashtag
> could have come into being ... o_O There is a clear identifier in the text
> ("§Cheese"), on which I only get notes where this identifier is also
> included, so with this I group the notes by an identifier according to some
> aspect. The advantage of this kind of "tagging" is that there is no
> duplication of information: if I used real tags (eg TiddlyWiki tags field),
> on the one hand I would have to add the tags corresponding to the
> components to the notes, on the other hand they would be in the text (where
> I describe the recipe itself). Instead, if I use "special links" as a tag,
> I only need to use it once, yet I can interpret the links as a tag. Eg the
> recipe for pizza:
>
> * Frozen [[§Pasta]]
> * 1/4 kg [[§Cheese]]
> * ...
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/6d5896f4-1562-4908-8f59-65b2c7835688o%40googlegroups.com.
