Tagging

[aphenine]

When I was looking around the database, I noticed that the tag database obeyed a tree form, which meant that tags could be stored with categories and subcategories and so on.

This is not a feature that's implemented, and it's high on my list of "features I'd love to have in DW" (possibly no 1 :-) ), and I have also written some tree algorithms using HTML/PHP before, so I thought I might try to give it a go and see if it went easily. However, when I went looking, there are no bugs in bugzilla about tree tagging, nor does there appear to be any information about this as a planned feature, despite the DB support.

So, I was wondering, can any of you please tell me more?

Comments

[aphenine]

Since I brought it up, I'll try to write a spec for it then, if you have no problems with that?

Obviously, I'd need some time to do that properly, but my thoughts were broadly that:

Divide the development into two stages:

1) Take the current usertag library and get it to work with tree tags. Use the colon syntax that is emerging as a standard so that "coding: perl" becomes coding -> perl in the DB and projects -> coding -> Dreamwidth becomes "projects: coding: Dreamwidth" in the tags. Change the count functions so that a count of perl in coding -> perl is a count of coding too and make sure the tag cloud works properly. Grab the S2 hack and get it to work on the tag list page.

2) Start a new library implementation. The library divides the two parts in tree tagging: building trees and printing them. Trees, once retrieved from the DB, are stored in nested structures of node objects. Code for this probably already exists, if not, gak C++ or PHP code to do similar (will be third language I write a node class in, *whinge*). Reason for division is to allow styles and other parts of code to handle the trees directly if they want to do cool things with them.

Building trees involves taking tree structures from the DB and building them into the above mentioned node form (and vice versa). Functions in threaded comments of DW do similar. Main function returns array of root tags from the DB, with child nodes stored inside them. Also need add/add_child functions in DB interface, and possibly move up/down if people want their tags ordered (no provision in DB for this at time).

Printing trees involves recursive functions to enable style writers to print trees simply as bulletted lists or other kinds of HTML lists (e.g. div tags), with the ability to add style info. Also, to print the necessary form for editting links (add, add_child, del).

Also, consider adding to DB a category marker, so that in coding -> perl, if coding is a category, coding does not exist as a tag, nor does a usage of perl count coding.

[mark]

So, a spec generally refers to the usage of a feature, not the development implementation. I mean, I want to know how this is going to be used on the site, what functionality it enables, what it's good for, what it's bad for, what benefits it brings, why we should do it, etc.

Technically, your comment looks reasonable, but I don't know what problem you're trying to solve with your particular implementation. I.e., without knowing what people want to do with the tags (and why they want hierarchical tags), it's going to be impossible to judge an implementation plan as good or bad.

Let's start with the usage of nested tags. How they appear on the site, what pages have to change, UI and behavior commentary, use cases, etc.

[aphenine]

mark, for section one, that's all covered. It's covered because there are implied assumptions that I thought were accepted, which are:

a) That people want hierarchical tags because they want to categorise their tags
b) That this would be done using the current tree system in the DB
c) That people are familiar with the S2 tag hack

Because b is a technical detail, the spec had to be technical too. Therefore, I can't make sense out of what you're asking, unless you're implying that I should be specifying this from scratch. Are you?

In the second section, I take your point, as I've gone beyond that. However, I'm not comfortable suggesting how the site should be changed, and I don't feel that those kind of specifications should be made by me.

Also it was my impression that the styles govern most of the look and feel of the site so that providing a toolset to coders/stylists would be good practice. Is this incorrect?

[mark]

So, I don't use hierarchical tags. I've never maintained a community that uses them. You seem to take for granted a lot of knowledge that I personally do not have, which is hindering my ability to participate in this conversation.

I have no idea what you want these nested tags for, what you intend to do with them, how they make your life better, why they're needed, or anything. Which means that, technically, it's not really a good use of time to discuss implementation on something I am not convinced we need (because I don't understand what it is you're saying we need).

For most feature development on Dreamwidth, we go through a few steps:

1) The suggestion is made, which outlines exactly what you want the feature to do. This is typically done in dw_suggestions via the Suggestion Submission Form and then people can vote and provide feedback to refine the idea until there's a solid idea.

2) The idea is then approved by Denise or myself and put in Bugzilla as a new bug.

3) Someone who is interested in the feature then writes up a formal feature specification. This formalizes everything about a particular feature. For example, Denise wrote a spec for overhauling memories. That spec makes a formal plan for what a feature MUST do, what it SHOULD do, and what it COULD do (implementation and time permitting). With suggestions for UI, pages that need changing, things to watch out for, etc.

4) Denise or I approve the spec in Bugzilla. (Or we reject it with commentary and the author updates it and resubmits.)

5) Someone takes the bug and begins a technical implementation. This includes what you're writing here; the technical spec for the implementation plan formalized by steps 1 and 3.

6) The implementor uploads a patch and requests a review.

7) The review happens. If it needs more work, the patch is rejected and the submitter has to update it with the feedback from the reeview.

8) The patch is committed.

9) The feature goes live.

So, from my point of view, you're jumping straight to the 5th step, and I am not clear on the first four steps. I don't understand this feature you want, what you want to do with it, and therefore I cannot judge whether or not the technical implementation you are proposing makes any sense.

Make more sense now? If you really want nested tags, then you should start at the first step. I promise it's not as painful as it sounds, and the feature will be much, much better for it. :)

[aphenine]

I'm sorry. I know about dw_suggestions and the suggestion process. If I'd known that I was proposing a completely new system, I would have gone through the established channels. I'm really not trying to short circuit anything and I really thought it was a developer query given that there is already support in the database and I was confused.

[mark]

Oh, don't be sorry! It's totally fine. If there were more than five lines of code and one database column, then you might be on to something. But really, there's not much support in the code for nested tags. Even if there was, we'd probably still at least go through everything from step #2. (We sometimes skip the suggestions process, but almost never skip the spec process.)

[cesy]

Can we get this put in Bugzilla, and then one of us will do a feature spec? Proper nested tags would be very useful.

[mark]

If you want to do so, go for it!

[av8rmike]

I don't know what problem you're trying to solve with your particular implementation.

I don't have a dog in this fight, so to speak, but individual tag length limit is one problem this implementation could conceivably fix. Nested tags right now aren't really nested, they just use a delimiter that the S2 code uses to split and display in different levels. The depth of the nesting is limited to whatever you can squeeze into the current 40-character limit. To use yvi's tags as examples, her longest is 40 characters, and looks to be cut off:

character:buffy-verse:wesley wyndam-pryc

With a true tag tree implementation, individual tags would still have a character limit, but the amount of nesting wouldn't be subject to the same limit (it'd have to have its own, I assume).