[Trac] Tags

[Muness Alrubaie]

On Wed, 5 Jan 2005 00:29:00 +0100, Christopher Lenz <cmlenz at gmx.de> wrote:
> Am 04.01.2005 um 20:29 schrieb Muness Alrubaie:
> > On Tue, 4 Jan 2005 19:06:38 +0100, Christopher Lenz <cmlenz at gmx.de>
> > wrote:
> >> Hi Muness,
> >>
> >> first, I think your work on tags in the trac wiki is pretty
> >> interesting. This is IMHO something that could go into Trac proper
> >> after the concept is worked out.
> >
> > Can we put a list together of what we should work out?  Or you can
> > feel free to post to the dev.muness.textdriven.com tags/Improvements
> > wiki entry.
> 
> I think this thread is okay for working out the concept.
> 
> >> Am 04.01.2005 um 16:51 schrieb Muness Alrubaie:
> >>> Alexey,
> >>>
> >>> 1) Some people prefer tag, others category, and others still label.
> >>> I
> >>> don't have a preference.  (The terms I think of is "overlapping
> >>> namespaces", but I don't think that'd ever be widely accepted.)  This
> >>> can be configurable so that people can use whichever terminology they
> >>> prefer.  Does that sound reasonable?
> >>
> >> Please no, let's just agree on one term. While it's tempting to create
> >> options for every situation where different people have different
> >> opinions, it's the road to chaos ;-)
> >>
> >> I personally prefer "tags", as used by Flickr and del.icio.us.
> >> "Labels"
> >> is okay.
> >
> > I vote for tags as well.  Again, I don't care much.
> >
> >>> 2) I started with organizing things hierarchically, hence the "/" all
> >>> over the place.  I think tagging/labelling/categorizing can do
> >>> everything hierarchies can do, but have not been inclined to actually
> >>> go ahead and make all hierarchical entries flat.  This may be the
> >>> best
> >>> thing to do.  What would be nice if I had a whole bunch of content to
> >>> tag and see how to best do things.  (Labels with hierarchies or
> >>> labels
> >>> with no hierarchies.)
> >>
> >> I see the value of hierarchical wiki names in easier linking to
> >> subpages. For example from "SomePage" I should be able to link to
> >> "SomePage/SubPageOne" simply by writing "/SubPageOne". Note that that
> >> improves both the readability and the writability of long page names,
> >> also compared to a flat namespace where I'd have to write
> >> "SomePageSubPageOne". (This sort of shortcut linking isn't currently
> >> implemented in Trac, but I really think it should be.)
> >
> > Agreed.  However, I think Chris Beck is right.  "/" would be weird.
> > "./" makes more sense to me.  I've started implementing this as a
> > macro.
> 
> /SubPage is a convention I know from UseMod (see
> http://www.usemod.com/cgi-bin/wiki.pl?UseModWiki). MoinMoin uses a
> similar convention described at
> http://moinmoin.wikiwikiweb.de/HelpOnEditing/SubPages. Using "./"
> actually implies linking to a page at the same level, not a sub-page.
> The basic problem here is that normal wiki names are absolute
> references, unlike file paths where absolute references always start
> with a slash (or drive letters on mediocre operation systems ;-) ).

I can get used to either, though I still find "./" more intuitive.

> 
> > I am already using shortcuts in labels. "." refers to self and .0
> > refers to top hierarchical element (SomePage in "SomePage/SubPageOne")
> > for example.  Maybe we should create a list of shortcuts and make them
> > work both in wiki references and labeling.
> 
> Not sure I understand... in what context are you using "." as shortcut?

In ListTags.  If you do a [[ListTags(.)]] this is equivalent to saying
[[ListTags(<Current Wiki Name>)]].

> 
> > An added advantage of using shortcuts is easier refactoring.
> 
> Agreed.
> 
> >> Generally I think tags/labels are often used in addition to hierarchy
> >> for organizing information.
> >
> > Using them together makes sense.  Hierarchies are for more obvious or
> > primary classifications.  Labels do everything else.
> >
> >> One thing I wonder about is whether tags should really be limited to
> >> wiki pages. Why not allow tagging of e.g. tickets and changesets?
> >> Possibly replacing the already existing keywords for tickets?
> >
> > I've thought of that.  Since I was new to Trac I really haven't had
> > much of a chance to explore the API it exposes to see if tickets and
> > changesets could be similarly tagged.
> 
> There's not much of an actual "API" exposed, really. But if tags are to
> be built into Trac as a core concept, it *might* make sense to support
> the concept throughout, not just for wiki pages. It's a pretty blurry
> idea at this point, but it might make more sense when tags start being
> used in practice.

Agreed.  It's a different way of organizing things, stranger than
del.icio.us where tags are pretty straightforward: just a collection
of links.  Here a tag is both a collection of wiki entries and a wiki
in and of itself.

Here's how I think of it: if I apply a tag (Books/ThinkingInJava) to a
wiki entry (Java) that means that Books/ThinkingInJava is relevant to
the Java context as well as the - explicit - Books context.

I think this doesn't really become obvious until you start using tags.

Anyway, so for changesets or tickets applying a tag to either may mean
that they make sense in the context of that wiki entry.  This may be
more expressive than the current implementation of component,
priority, version, and "assign to" fields.

If each of those fields, instead of being strings of texts are instead
wiki entries, a user can just click on them and see what they are. 
Sort of like they do for milestones.

> 
> > Also does the reverse make sense: should we allow using a ticket as a
> > tag?
> 
> Interesting... so you could e.g. mark wiki pages as being related to a
> ticket by tagging them with the ticket ID?

Exactly.  Say someone creates a wiki entry that fits underneath the
ticket.  By doing this, they can easily set the context of the wiki
entry pretty quickly.  This would be flipping the milestone concept on
its head.

I am going to go out on a limb and suggest this be something that is
implemented later.  Seems powerful, but may require more refactoring
than is desired at this point.  You're more familiar with Trac and
what's going on with it, so you take on this is more useful.

> 
> I really need to check out how you're using tags more closely.

That's what I want to hear.  ;)

They're not completely clear in my head yet, but I am fairly sure that
applying tagging to wikis gives us ways of organizing things that
we've not had before.  I think after using it for a while it'll feel a
lot more intuitive than strict hierarchical organizations.

One of the papers I think is very useful to seeing this is Christopher
Alexander's A City is Not a Tree, available at
http://www.rudi.net/bookshelf/classics/city/alexander/alexander1.shtml
.  It outlines the difficulties and shortcomings of using hierarchies.

> 
> Cheers,
> Chris
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
> 
> 


Muness

-- 
See my blog at http://muness.blogspot.com