Hi Mat,
 

> We can use tags to *categorize* and elegantly *structure* tiddlers.
> This takes logic and *thinking* to do. 


This is the only use I have for tags,
(besides perhaps having a functional aspect, e.g. system tags).

I find tagging rather intuitive.
No heavy-weight thinking or permanent structuring.

In short, *a tag defines a parent => child relationship*,
whereas each tiddler tagging to it is some form of offspring.
If you turn that paradigm around,
you're putting the cart before the horse.
 

> But quite as often, tags are used in the much more ephemeral activity; 
> *searching*.
>

As explained at that Hidden Tags ticket (#1366) 
<https://github.com/Jermolene/TiddlyWiki5/issues/1366>,
this is not at all what I relate with tags in TiddlyWiki.
This kind of use simply clutters the "*tag-space*" for *no* good reason.

The kind of tags you say you wish to define, e.g.
"I need to attach this very long reminder to that tiddler"
...clearly are not in any way parent to that tiddler.
They are, in fact, (perhaps actionable) children that should be
tiddlers themselves, tagging to the tiddler they refer to,
and categories like *task*, *action* or *reference*, etc...
So, use *new here*.

Tagging is of course a key feature for effective search.
>

True. Searching by tag should actually take precedence over non-tag 
tiddlers,
as tags are more higher-level than any children pointing to them.

But the *best* tags for search efficiency are not at all necessarily those 
> carefully thought out and pretty "category tags" but instead actually 
> whatever pops into your mind!
>

We all have those "pops into my mind" moments.
However, I think most of that should be part of the content.
Otherwise your content may be severely lacking in body.
Then,if it's not a parent thing, i.e. a tag,
it is a child, so make it a tiddler tagging to this one. — Simple.
 

> Now, how should I tag this tiddler?


Simple, add:

   1. *a tag*
      - everything that is a worthy parent category
         - likely to have +1 other tiddlers tagging to it
      2. *the text*
      - everything in need of mentioning
         - not a categorization, just a textual reference
         - perhaps even a link 
      3. *a child *tiddler (tagging to this one) — *new here*
      - when things that would explode this tiddler
         - and thus need to be extracted into their own little tiddler
      
Well, with some *category* tags for sure;  TWconcept, IdeaRank4, mockup. 
> But I would really also want the much more associative aspects: graphics, 
> illustration, paint.net, railroad, Astrid, draft, sketch, notation, 
> model, Duarte


Again, you can easily do the above differentiation and
put your keywords either into the *tags* or directly into the *text*.

Having keywords that are neither seems counter productive to me as
you were not explicit as to where and how they relates to the actual 
content of this tiddler.

If you still think you need those,
visually separate them from everything that is neither tag nor content,
simply by ending your tiddler like so...

; keywords
: foo, bar, baz

...or a keywords macro, rendering the above output in a style that can 
later be changed...

<<keywords foo, bar, baz>>

with...

\define keywords()

; keywords
: <<paramString>>
\end

Which reminds me that I do want that variable.

However, notice how his does not introduce some artificial keywords field,
simply an enumeration of keywords you wish to find content by,
keywords that are not anywhere in the content and also not used as tags.

Of course, if you want to, you could also create that keywords field
at every tiddler where you want it and then
amend search with a search results tab for keywords 
<http://tb5.tiddlyspot.com/#Custom%20Search%20Tab%20Exact>.

To display keywords at the bottom of every tiddler that defines them,
simply create a Conditional ViewTemplate Section 
<http://tb5.tiddlyspot.com/#Conditional%20ViewTemplate%20Section>
calling the above macro to render the keywords.

But don't use the tags field when something is not a (parent) tag!

However [referring to the github thread] a consequence of this is a lot of 
> tags that you don't want to see immediately.


That's why I say: Change your method, not the core.

Be clear about...

   - what's a parent
   - what's a child
   - what's content
   - what's a property (field)

And that's it!

It is obvious to me that you run into a multitude of somewhat artificial 
problems
when you wish to repurpose something that it has not been designed for,
e.g. turning that implicit *parent => child* paradigm of tags on its head.

Best wishes, Tobias.

-- 
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

Reply via email to