Extending TagSearch / Tagging
12 views
Skip to first unread message
Tobias Beer
Oct 18, 2010, 3:23:37 AM10/18/10
to TiddlyWiki
This is in reply to Plausible's post [1] and I would appreciate some
feedback as to whether or not you would want to see an implementation
for this, too... and if so, which variant.
> Tried a bunch of other tagging plugins
> and now I'm using Tobias's TagSearchPlugin.
> (Tobias: this is neat, though
> making 10 tag tiddlers each itself tagged e.g.
> 'Topic' is more convoluted than
> if one could have 1 tiddler 'Topic'
> with a list of ten tags in it...
> I bet I'm overlooking the pros of your system.)
For a while now, we're able to not just use tags as mere pointers but
also to promote them to first class citizens ...a design tenet of
which I made extensive use in tbGTD [2]. They're a good starting point
if not only to get a list of tiddlers pointing to them.
On the other hand, it is true that your TiddlyWiki were more compact
if your categories in one way or the other only had a reference to the
corresponding category values. So here are some variants for achieving
this.
Variant A) Using a section...
tiddler 'action'
!Tags
#future
#queued
#next
#waiting
#done
...possibly wrapped like this if you didn't want to have them on
display:
/%
!Tags
...
!EndTags
%/
Variant B) Using some field, e.g.
tiddler 'action' {tags:"#future #queued #next #waiting #done")
Variant 3) Save sections in your TagSearchConfig named like the
category that you want to use and put the corresponding values into
that section ...triggered by another parameter, e.g.
cats:TagSearchConfig. Using slices somewhat is not an option as they
must not contain empty spaces, whereas your category titles just
might ...although, one might replace them with underscores and thus
make that work too.
I would tend to prefer 3) ...however, all three alternatives are not
overly difficult to implement, so that might be a welcome addition
giving you the flexibility to only promote tags to first class
citizens when you really want to.
Benefits of all three variants would be that you were able to...
#sort your category values the way you want
#leave out some, perhaps because they're not that important
All three would require you to store categories as a bracketedList
[3].
I would, however, see this as an [either<>or] approach. Thus, if you
devise such a section or field then it will be used; otherwise the
tiddlers tagging to the category tiddler will be used.
Variant 4) would be to allow for all three alternatives, whereas...
cats:@Tags -> lookup section 'Tags' in the category tiddler
cats:%tags -> lookup field 'tags' in the category tiddler
cats:TagSearchConfig -> look for a section corresponding to the
category title in that tiddler
default: Use tiddlers tagging to the category
On the other hand, there would be no known relation between a 'topic'
tiddler and the individual topics, unless other plugins would (be able
to) use the same lookup mechanism as it were implemented for
TagSearch.
So, either this is some form of 'poor man's tagging' or it is a neat
enhacement to bind tags to categories for when you have no desires to
promote your tags to first class citizens. Your call.
Cheers, Tobias.
[1] http://groups.google.com/group/tiddlywiki/msg/ff68dafd4fa2213c
[2] http://tbgtd.tiddlyspot.com
[3] 'foo [[bar baz]] "mumble grotz" fronk'
feedback as to whether or not you would want to see an implementation
for this, too... and if so, which variant.
> Tried a bunch of other tagging plugins
> and now I'm using Tobias's TagSearchPlugin.
> (Tobias: this is neat, though
> making 10 tag tiddlers each itself tagged e.g.
> 'Topic' is more convoluted than
> if one could have 1 tiddler 'Topic'
> with a list of ten tags in it...
> I bet I'm overlooking the pros of your system.)
For a while now, we're able to not just use tags as mere pointers but
also to promote them to first class citizens ...a design tenet of
which I made extensive use in tbGTD [2]. They're a good starting point
if not only to get a list of tiddlers pointing to them.
On the other hand, it is true that your TiddlyWiki were more compact
if your categories in one way or the other only had a reference to the
corresponding category values. So here are some variants for achieving
this.
Variant A) Using a section...
tiddler 'action'
!Tags
#future
#queued
#next
#waiting
#done
...possibly wrapped like this if you didn't want to have them on
display:
/%
!Tags
...
!EndTags
%/
Variant B) Using some field, e.g.
tiddler 'action' {tags:"#future #queued #next #waiting #done")
Variant 3) Save sections in your TagSearchConfig named like the
category that you want to use and put the corresponding values into
that section ...triggered by another parameter, e.g.
cats:TagSearchConfig. Using slices somewhat is not an option as they
must not contain empty spaces, whereas your category titles just
might ...although, one might replace them with underscores and thus
make that work too.
I would tend to prefer 3) ...however, all three alternatives are not
overly difficult to implement, so that might be a welcome addition
giving you the flexibility to only promote tags to first class
citizens when you really want to.
Benefits of all three variants would be that you were able to...
#sort your category values the way you want
#leave out some, perhaps because they're not that important
All three would require you to store categories as a bracketedList
[3].
I would, however, see this as an [either<>or] approach. Thus, if you
devise such a section or field then it will be used; otherwise the
tiddlers tagging to the category tiddler will be used.
Variant 4) would be to allow for all three alternatives, whereas...
cats:@Tags -> lookup section 'Tags' in the category tiddler
cats:%tags -> lookup field 'tags' in the category tiddler
cats:TagSearchConfig -> look for a section corresponding to the
category title in that tiddler
default: Use tiddlers tagging to the category
On the other hand, there would be no known relation between a 'topic'
tiddler and the individual topics, unless other plugins would (be able
to) use the same lookup mechanism as it were implemented for
TagSearch.
So, either this is some form of 'poor man's tagging' or it is a neat
enhacement to bind tags to categories for when you have no desires to
promote your tags to first class citizens. Your call.
Cheers, Tobias.
[1] http://groups.google.com/group/tiddlywiki/msg/ff68dafd4fa2213c
[2] http://tbgtd.tiddlyspot.com
[3] 'foo [[bar baz]] "mumble grotz" fronk'
Plausible
Oct 18, 2010, 1:15:13 PM10/18/10
to TiddlyWiki
Aloha,
I had a better look at TagSearchConfig just now. What I'd find fairly
intuitive seems like your option (3). Something like TagSearchConfig
reading:
!Tags
[[Planet]]
[[RocketType]]
!Priority
[[high]]
[[low]]
!More
[[sysTag]]
[[strayThought]]
where none of the things between [[]] are actual tiddlers... Planet
and RocketType are categories each with a number of 'first class
citizen' tag-tiddlers tagging to them (e.g. #Mercury could tag to
Planet AND give some info on Mercury, too); whereas high and low are
'poor man's tags' (there's no need for them to be a tiddler).
It's still pretty non-intuitive to the uninitiated though, as the same
syntax is used for different things: [[sysTag]] and [[high]] for
example are /tags/ whereas [[Planet]] is a /category/. It took me a
while to realise this, looking at the default TagSearchConfig.
How about instead something like:
¹¹¹ 1st class citizens ¹¹¹
!Planet
[[Mercury]]
[[Venus]]
!RocketType
[[Soyuz]]
[[Ariane]]
²²² poor dudes ²²²
!Priority
[[high]]
[[low]]
!More
[[sysTag]]
[[strayThought]]
I just use the ¹ and ² to indicate 'some syntax' so that when
TagSearchConfig is saved, the tags listed under ¹¹¹ (but before ²²²)
automatically get a tiddler of their own with a tag pointing at their
category, whereas the ones under ²²² don't. (Possible? No idea.)
I guess this breaks the source:.../more:... parameter syntax, but that
one is sort of complex in any case... would be nice if you could just
write <<tagsearch myTagSearchConfig>>. If you want a "More" section of
uncategorised tags, put it in myTagSearchConfig; if you don't, then
don't; etcetera.
Not considering/grasping all technical details here so pardon my
naivety.
~P
I had a better look at TagSearchConfig just now. What I'd find fairly
intuitive seems like your option (3). Something like TagSearchConfig
reading:
!Tags
[[Planet]]
[[RocketType]]
!Priority
[[high]]
[[low]]
!More
[[sysTag]]
[[strayThought]]
where none of the things between [[]] are actual tiddlers... Planet
and RocketType are categories each with a number of 'first class
citizen' tag-tiddlers tagging to them (e.g. #Mercury could tag to
Planet AND give some info on Mercury, too); whereas high and low are
'poor man's tags' (there's no need for them to be a tiddler).
It's still pretty non-intuitive to the uninitiated though, as the same
syntax is used for different things: [[sysTag]] and [[high]] for
example are /tags/ whereas [[Planet]] is a /category/. It took me a
while to realise this, looking at the default TagSearchConfig.
How about instead something like:
¹¹¹ 1st class citizens ¹¹¹
!Planet
[[Mercury]]
[[Venus]]
!RocketType
[[Soyuz]]
[[Ariane]]
²²² poor dudes ²²²
!Priority
[[high]]
[[low]]
!More
[[sysTag]]
[[strayThought]]
I just use the ¹ and ² to indicate 'some syntax' so that when
TagSearchConfig is saved, the tags listed under ¹¹¹ (but before ²²²)
automatically get a tiddler of their own with a tag pointing at their
category, whereas the ones under ²²² don't. (Possible? No idea.)
I guess this breaks the source:.../more:... parameter syntax, but that
one is sort of complex in any case... would be nice if you could just
write <<tagsearch myTagSearchConfig>>. If you want a "More" section of
uncategorised tags, put it in myTagSearchConfig; if you don't, then
don't; etcetera.
Not considering/grasping all technical details here so pardon my
naivety.
~P
Saverio
Oct 18, 2010, 4:08:23 PM10/18/10
to TiddlyWiki
I was reminded of one of Eric Shulman's plugins (http://
www.tiddlytools.com/#ListboxPluginInfo), in which list items can be
specified in a number of ways:
1) inline list definition (ie "value value value")
2) tiddler-based list definition ("+TiddlerName" to use a horizontal-
rule separated list in TiddlerName, or "*TiddlerName" to first process
TiddlerName through the TW parser before looking for the horizontal-
rule separated list)
3) tag-based list defintions ("=tagvalue" or "=tag expression")
Perhaps using a similar convention would be a way to implement Variant
4?
On Oct 18, 3:23 am, Tobias Beer <beertob...@googlemail.com> wrote:
> This is in reply to Plausible's post [1] and I would appreciate some
> feedback as to whether or not you would want to see an implementation
> for this, too... and if so, which variant.
>
www.tiddlytools.com/#ListboxPluginInfo), in which list items can be
specified in a number of ways:
1) inline list definition (ie "value value value")
2) tiddler-based list definition ("+TiddlerName" to use a horizontal-
rule separated list in TiddlerName, or "*TiddlerName" to first process
TiddlerName through the TW parser before looking for the horizontal-
rule separated list)
3) tag-based list defintions ("=tagvalue" or "=tag expression")
Perhaps using a similar convention would be a way to implement Variant
4?
On Oct 18, 3:23 am, Tobias Beer <beertob...@googlemail.com> wrote:
> This is in reply to Plausible's post [1] and I would appreciate some
> feedback as to whether or not you would want to see an implementation
> for this, too... and if so, which variant.
>
Tobias Beer
Oct 18, 2010, 4:11:52 PM10/18/10
to TiddlyWiki
First of all, there is no need to have square brackets around the
items in TagSearchConfig. I have only used them to be able to click
them. As mentioned in the first post, the section contents really are
bracketed lists. See [3] for the post above.
I would never have TagSearchPlugin create any tiddler for which there
is an entry in some section in TagSearchConfig. It is up to the user
to do that. Just use any category for which there is no tiddler yet
and you will see it should be italicized and rightfully so.
So, TagSearchConfig along with an implementation of your idea would in
its most simple form look like this...
!Tags
Planet
RocketType
!Priority
high
low
!More
sysTag
strayThought
And the corresponding macro call like this...
<<tagsearch source:TagSearchConfig##Tags more:TagSearchConfig##More
cats:TagSearchConfig>>
The reason why I haven't set it up as just one TagSeachConfig was that
there might be cases where in general you would use it like the above
but in some inline context, maybe together with some fET, you would
use it like this...
<<tagsearch source:SomeOther::TagList cats:TagSearchConfig>>
Thus, it is not evident that all of the config stuff you want to use
comes from one tiddler, which is especially true if you actually
wanted different sections but only one config tiddler, e.g.
<<tagsearch source:TagSearchConfig##TagList2 cats:TagSearchConfig>>
It could however be simplified such that you could say...
<<tagsearch config:TagSearchConfig>>
...which would look for a "Tags" and a "More" and possibly some
category sections or even other parameters in the form of slices, a
procedure I have used in FiltrPlugin [1] and which I now think might
be good to also use for TagSearchPlugin to simplify the general setup
and also the ability of others to share config-templates.
Cheers, Tobias.
[1] http://tobibeer.tiddlyspace.com/#Filtr
items in TagSearchConfig. I have only used them to be able to click
them. As mentioned in the first post, the section contents really are
bracketed lists. See [3] for the post above.
I would never have TagSearchPlugin create any tiddler for which there
is an entry in some section in TagSearchConfig. It is up to the user
to do that. Just use any category for which there is no tiddler yet
and you will see it should be italicized and rightfully so.
So, TagSearchConfig along with an implementation of your idea would in
its most simple form look like this...
!Tags
Planet
RocketType
!Priority
high
low
!More
sysTag
strayThought
<<tagsearch source:TagSearchConfig##Tags more:TagSearchConfig##More
cats:TagSearchConfig>>
The reason why I haven't set it up as just one TagSeachConfig was that
there might be cases where in general you would use it like the above
but in some inline context, maybe together with some fET, you would
use it like this...
<<tagsearch source:SomeOther::TagList cats:TagSearchConfig>>
Thus, it is not evident that all of the config stuff you want to use
comes from one tiddler, which is especially true if you actually
wanted different sections but only one config tiddler, e.g.
<<tagsearch source:TagSearchConfig##TagList2 cats:TagSearchConfig>>
It could however be simplified such that you could say...
<<tagsearch config:TagSearchConfig>>
...which would look for a "Tags" and a "More" and possibly some
category sections or even other parameters in the form of slices, a
procedure I have used in FiltrPlugin [1] and which I now think might
be good to also use for TagSearchPlugin to simplify the general setup
and also the ability of others to share config-templates.
Cheers, Tobias.
[1] http://tobibeer.tiddlyspace.com/#Filtr
Plausible
Oct 19, 2010, 6:12:36 AM10/19/10
to TiddlyWiki
Hello Tobias,
> I would never have TagSearchPlugin create any tiddler for which there
> is an entry in some section in TagSearchConfig. It is up to the user
> to do that.
Why not though? If one wants a dozen '1st class' tags which carry the
same category tag (e.g. Jan, Feb, ... all tagged 'Month'), it is
tedious to give that category tag to each of them by hand. Consider
that with a number of categories... I figure it could be much quicker
to write a list of the whole structure and generate tiddlers and tags
automatically from that.
> So, TagSearchConfig along with an implementation of your idea would in
> its most simple form look like this...
>
> !Tags
> Planet
> RocketType
> !Priority
> high
> low
> !More
> sysTag
> strayThought
>
> And the corresponding macro call like this...
> <<tagsearch source:TagSearchConfig##Tags more:TagSearchConfig##More
> cats:TagSearchConfig>>
Well, this still puts categories (Planet, RocketType) on the same
syntactical level as category values (high, low) and 'independent'
tags. Likewise a category can be a section heading (Priority, More --
'More' also seems a kind of category) or not (Planets, RocketType). It
may work code-wise but it's hard to grasp for the end user, I think.
Maybe I'm fundamentally misunderstanding this.
> Thus, it is not evident that all of the config stuff you want to use
> comes from one tiddler, which is especially true if you actually
> wanted different sections but only one config tiddler, e.g.
>
> <<tagsearch source:TagSearchConfig##TagList2 cats:TagSearchConfig>>
>
> It could however be simplified such that you could say...
> <<tagsearch config:TagSearchConfig>>
The simplification would be handy. But I see your reason for using the
params. I don't know how to combine that with the syntax change I'm
thinking of above... is it possible to nest sections?
cheers, ~P
> I would never have TagSearchPlugin create any tiddler for which there
> is an entry in some section in TagSearchConfig. It is up to the user
> to do that.
same category tag (e.g. Jan, Feb, ... all tagged 'Month'), it is
tedious to give that category tag to each of them by hand. Consider
that with a number of categories... I figure it could be much quicker
to write a list of the whole structure and generate tiddlers and tags
automatically from that.
> So, TagSearchConfig along with an implementation of your idea would in
> its most simple form look like this...
>
> !Tags
> Planet
> RocketType
> !Priority
> high
> low
> !More
> sysTag
> strayThought
>
> And the corresponding macro call like this...
> <<tagsearch source:TagSearchConfig##Tags more:TagSearchConfig##More
> cats:TagSearchConfig>>
syntactical level as category values (high, low) and 'independent'
tags. Likewise a category can be a section heading (Priority, More --
'More' also seems a kind of category) or not (Planets, RocketType). It
may work code-wise but it's hard to grasp for the end user, I think.
Maybe I'm fundamentally misunderstanding this.
> Thus, it is not evident that all of the config stuff you want to use
> comes from one tiddler, which is especially true if you actually
> wanted different sections but only one config tiddler, e.g.
>
> <<tagsearch source:TagSearchConfig##TagList2 cats:TagSearchConfig>>
>
> It could however be simplified such that you could say...
> <<tagsearch config:TagSearchConfig>>
params. I don't know how to combine that with the syntax change I'm
thinking of above... is it possible to nest sections?
cheers, ~P
Tobias Beer
Oct 19, 2010, 7:00:15 AM10/19/10
to TiddlyWiki
> > I would never have TagSearchPlugin create any tiddler for which there
> > is an entry in some section in TagSearchConfig. It is up to the user
> > to do that.
>
> Why not though? If one wants a dozen '1st class' tags which carry the
> same category tag (e.g. Jan, Feb, ... all tagged 'Month'), it is
> tedious to give that category tag to each of them by hand. Consider
> that with a number of categories... I figure it could be much quicker
> to write a list of the whole structure and generate tiddlers and tags
> automatically from that.
Maybe there is some misunderstanding. If a tag that you want to use in
> > is an entry in some section in TagSearchConfig. It is up to the user
> > to do that.
>
> Why not though? If one wants a dozen '1st class' tags which carry the
> same category tag (e.g. Jan, Feb, ... all tagged 'Month'), it is
> tedious to give that category tag to each of them by hand. Consider
> that with a number of categories... I figure it could be much quicker
> to write a list of the whole structure and generate tiddlers and tags
> automatically from that.
TagSearch - pertaining to some category - doesn't exist yet ...then
that would not prevent it from being displayed in the TagSearch
interface.
Instead, they would look like tiddlyLinks to non existing tiddlers,
yet you could use the checkbox to assign them as tags ...that however
would not be true for the searchbox, which only presents you with
existing tiddlers.
The important reasons for not overcomplicating the code by
automatically creating some tiddlers while others not are the
following...
1) Its kind of a one time only task for a mere handful of items.
2) If you really wanted these items to be tiddlers, you are going to
want to input some text, too ... so you'll probably have to touch them
one by one anyways.
Besides, if you'd open those non existing tag tiddlers, tagging
tiddlers would still be show in the tiddler.
A simple option might be to have a little helper script, that prompts
you for some section of some tiddler - corresponding to a section with
titles of tiddler that you want to create, maybe defined in some
TagSearchConfig or maybe somewhere else - then looks up that section
via store.getTiddlerText('SomeTiddler##SomeSection'), does a
readBracketedList() on the text contents and then creates any non
existing tiddlers via store.saveTiddler().
I wouldn't know about your coding experiences, but that would be a
neat little task for a first hand experience with some (TW) javascript
code... whereas the dev section of tiddlywiki.org would sure help you
out with further information on the above mentioned functions, e.g.:
http://tiddlywiki.org/wiki/Dev:SaveTiddler
Cheers, Tobias.
Message has been deleted
Tobias Beer
Oct 19, 2010, 7:07:58 AM10/19/10
to TiddlyWiki
> that however would not be true for the searchbox,
> which only presents you with existing tiddlers.
Well, looks like I have to correct myself here. If something is used
> which only presents you with existing tiddlers.
as a tag, then the almighty GotoPlugin-searchbox does take care of it,
too, and displays it in the results like this:
sometag (tag)
Cheers, Tobias.
Plausible
Oct 19, 2010, 1:07:44 PM10/19/10
to TiddlyWiki
> Maybe there is some misunderstanding. If a tag that you want to use in
> TagSearch - pertaining to some category - doesn't exist yet ...then
> that would not prevent it from being displayed in the TagSearch
> interface.
>
> Instead, they would look like tiddlyLinks to non existing tiddlers,
> yet you could use the checkbox to assign them as tags ...
Yeah, I sort of figured it out... so the /categories/ under !Tags can
> TagSearch - pertaining to some category - doesn't exist yet ...then
> that would not prevent it from being displayed in the TagSearch
> interface.
>
> Instead, they would look like tiddlyLinks to non existing tiddlers,
> yet you could use the checkbox to assign them as tags ...
be tiddlers, or ghost tiddlers, or just tiddler-less words: either is
fine. Same for the /tags/ under !More. However the options within a
category must be a tiddler each (so that they can tag to the
category).
So my suggestion was to allow for options within a category that are
just tiddler-less words. And (if I'm not mistaken) that's what you
propose to answer with e.g. the cats: addition. I bet that would work;
yet for the newbie wanting to write their TagSearchConfig it might
still be confusing for the syntax-related reason I mentioned. I.e.
there's a visual conflation of tags that are 'single-level' (e.g.
Talks in http://tobibeer.tiddlyspace.com/#TagSearchConfig) and tags
that are a category for other tags (e.g. Contributions).
I'm sure you'll sort it out :)
> The important reasons for not overcomplicating the code by
> automatically creating some tiddlers while others not are the
> following...
> A simple option might be to have a little helper script...
>
> I wouldn't know about your coding experiences, but that would be a
> neat little task for a first hand experience with some (TW) javascript
Right now I mainly just want to get my TW-unrelated TSpace working.
> I wouldn't know about your coding experiences, but that would be a
> neat little task for a first hand experience with some (TW) javascript
Can't afford to pick up javascript now; but it's interesting so I may
give it a shot at a later date.
cheers, ~P
Reply all
Reply to author
Forward
0 new messages