TagglyTagging and extensible tiddler metadata braindump
Simon Baird
* How to migrate an existing tagglyTagging structure?
Clint Checketts
I think when extensible tiddler meta data comes along the first thing I might want to do with it is create a "parentTiddler" field and use it to do TagglyTagging style hierarchies. If we allow multiple parent tiddlers then we keep that lovely TagglyTagging flexibility that we know and love.
This is interesting. Though I view TagglyTagging as a good use of tags. To me a parent is one step up.
Thoughts? Comments? Am I nuts? Jeremy, what do you think about parentTiddler and and hierarchies built into 2.1.1??
I'm not Jeremy and the parentTiddler idea has merit, but seems too soon to decide to include it in future TWs. Let's see how it feels as a plugin first.
-Clint
Luke Blanshard
Simon Baird wrote:
> Using tags to create tiddler hierarchies has always been a little bit of a
> misuse of tagging. One of the objections to TagglyTagging is that it muddies
> the concept of what tagging is, and I agree actually (though a little mud
> never bothered me much.. :)
I have to say, I don't agree with this objection. The beauty of the
word "tag" is its complete lack of semantic content. Tagging is
whatever you want it to be, and TagglyTagging is just as legitimate as
the more common del.icio.us-style approach.
> I think when extensible tiddler meta data comes along the first thing I
> might want to do with it is create a "parentTiddler" field and use it to do
> TagglyTagging style hierarchies. If we allow multiple parent tiddlers then
> we keep that lovely TagglyTagging flexibility that we know and love.
I can see doing this kind of thing for lots of things that people have
been using tags for -- like for view/edit templates. But not for
TagglyTagging. My view.
Luke
Saq Imtiaz
> I think when extensible tiddler meta data comes along the first thing I
> might want to do with it is create a "parentTiddler" field and use it to do
> TagglyTagging style hierarchies. If we allow multiple parent tiddlers then
> we keep that lovely TagglyTagging flexibility that we know and love.
I can see doing this kind of thing for lots of things that people have
been using tags for -- like for view/edit templates. But not for
TagglyTagging. My view.
I have to agree with Luke here. Personally, one of two reasons that I am looking forward to EMD is so that there is an alternative to adding tags to 'identify' tiddlers. That said, I think it only makes sense to resort to using EMD where an 'invisible tag' is desired.
In TagglyTagging its very useful to be able to see the tags, and more often that not they actually make sense in context. It's the tags that we don't want end users to see, they are the ones that we should be using EMD for. A good example may be the marking of tasks as Done in a GTD situation. Especially if the tiddler text shows the Status of the task, the tag is unnecessary. Similary, do we really need to tag a task as 'task' if the ViewTemplate used for it already makes it obvious as to what is is?
Those might not have been the best examples, but I think you will follow my meaning here. In short, keep it simple. Using EMD only when you need to hide the 'tags' from the user.
Cheers,
Saq
Daniel Baird
Using EMD for representing relationships (not even just heirarchical tag relationships) will mean you can give relationships a meaning.
Eg, a tiddler representing Person A could have links to Person A's parents, children, etc and each link could have a descriptor. Can't do that with tags.
I don't think that taggly heirarchies will be replaced though.
;D
--
Daniel Baird
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog :: Things That Suck)
Jeremy Ruston
> and and hierarchies built into 2.1.1??
Short answer: go for it, and let's see what people think.
Long answer: being able to cheaply experiment with ideas like this is
definitely a big motivator for the EMD stuff. There's quite a few
other wikis that have the concept of a parent (TWiki I'm the most
familiar with), and it does give some nice ways of providing
navigation. However, I found that users weren't really aware of the
field or how to change it, and so stuck with whatever default parent
was specified when the page was created, which was not always correct.
The observation might not apply to us: I get the impression that a lot
of TiddlyWiki users are very disciplined in the way that they
structure their data.
Cheers
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Jules
Hierarchies should exist in parallel to tags without a doubt. So the
tagging still needs to exist.
I want, I want!
--
Jules
www.knightnet.org.uk
http://knighjm.googlepages.com/knightnet-default-tw.html
Udo Borkowski
"parentTiddler" field since I assume that other people may also define
some tiddler hierarchy that may not match the one that you (/
TagglyTagging) are looking for.
This is also the reason why I personally would not introduce the concept
of a "hierarchy" into the TiddlyWiki because it is not obvious what
this hierarchy should reflect. Does it mean things like "belongs to",
"is specification of" , "in Instance of " and all these other things one
may have in mind when talking about a "hierarchy".
But let's assume it should go in the core: what would you assume should
be the "core" support for a "parentTiddler" field, other than providing
a uniform way to specify and display it? Should it check for cycles or
do any other kind of checks? What makes this field different from other
meta data fields people may come up the future (like "creator", "rating"
etc.) to put "parentTiddler" into the core?
Udo
Simon Baird
I suggest that you create a "tagglyParent" field instead of a
"parentTiddler" field since I assume that other people may also define
some tiddler hierarchy that may not match the one that you (/
TagglyTagging) are looking for.
I'm not sure of the need to have more than tiddler hierachy. Especially if multiple parents are allowed. All the different hierachies you need can coexist.
This is also the reason why I personally would not introduce the concept
of a "hierarchy" into the TiddlyWiki because it is not obvious what
this hierarchy should reflect. Does it mean things like "belongs to",
"is specification of" , "in Instance of " and all these other things one
may have in mind when talking about a "hierarchy".
Actually I take that back my previous sentence. Perhaps a more generic solution is to have arbitrary named relationships between tiddlers.
Eg, (not functions but metadata tuples of some kind)
relationship("parent"."MyParent",)
relationship("next","MyNextPage")
relationship("docsFor","DocsTiddler")
relationship("tag","SomeTag") // this is what we call a tag now. in a sense this is a superset of tagging
The tags box could have multiple headings, eg:
+----------------+
Related:
* Tags
** SomeTag
* Next
** MyNextPage
* Documentation
** DocsTiddler
* Parent
** MyParent
+-----------------+
Maybe this is beyond the realm of what most people need, but you could do some neat things with it.
Also it's possible that tiddler hierachies are beyond the realm of what most people need but users of TagglyTagging (myself included) might not think so.
But let's assume it should go in the core: what would you assume should
be the "core" support for a "parentTiddler" field, other than providing
a uniform way to specify and display it? Should it check for cycles or
do any other kind of checks? What makes this field different from other
meta data fields people may come up the future (like "creator", "rating"
etc.) to put "parentTiddler" into the core?
I was suggesting that being able to specify a hierachical relationships between tiddlers might be worth considering as a new basic capability for TW. The implementation details are not important but if it was to be done first as a plugin then I was guessing a meta data field would be a good way to do it.
Udo
Responding to this discussion in general, there are some votes and sound arguments in either direction. I don't think I have reached my own conclusion as to whether it is a good idea or not. (I like Luke's quote that tags are whatever you want them to be). But one thing is clear, tiddler meta data will open many possibilities.
Simon.
--
Simon Baird <simon...@gmail.com>
Daniel Baird
So, really, you're saying that we should have a convention to represent relationships between tiddlers. I'm particularly excited by the idea that you could define "next" and "previous" links, and also the idea of a family-tree TW.
It's true that you could write a plugin that had all the conventions built in, but I'd like to see an agreement about how these relationships are stored. That way, one plugin could concentrate on importing a GEDCOM family tree, and another plugin could do the display of the family tree relationships. As long as there's a standard for relationship storage they could work together.
I think there's a reasonable place for a structure like this:
relationship:
1 x otherTiddler (to whom the relationship is directed)
1 x relnType (eg "Next", "Parent", "Docs" etc)
1 x flavour (so that you can have multiple relns of the same type)
The "flavour" (sorry I couldn't think of a better word:) of a relationship could be used so that if you're using Next links, and you have a tiddler InstallingPlugins, that tiddler could be part of two or more tutorial paths. Eg a "quick start tutorial" path might go: DownloadingTW -> SettingUp -> InstallingPlugins -> SavingToAServer, and a "plugin tutorial" path could go WhatIsAPlugin -> InstallingPlugins -> WritingAPlugin.
In that example, InstallingPlugins would have these two links:
relnType: "next"
otherTiddler: "SavingToAServer"
flavour: "Quick Start Tutorial"
and..
relnType: "next"
otherTiddler: "WritingAPlugin"
flavour: "Plugin Tutorial"
..so some plugin can show a nice little <=prev / next=> thing for whatever path, or all paths, or whatever.
Wotcha all think?