Tags 2.0

[admin]

"Tag" as currently used is a misnomer.

Over the recent months it became clear that most users expect a situation where many tags can be attributed to a single item. Like keywords. This is also common usage in tag clouds and other tagging stuff in the web.

Now I plan to add this type of tagging (very useful for photo or sound collections!). And call it "Tags". So we will have three different kind of data in the tag.dat database:

Tags: many tags per item.
Comments: one comment per item.
???: one ??? per item.

??? is what's currently called "Tag". This needs a new name. Here are some suggestions:
Color, Label, Category.
You got a better suggestion?

[Pagat]

i'd go for "Label", since it's also used in most email applications where you can label your mails with exactly one "label" per item.

[TheQwerty]

I'd immediately think Label or Category.

Both are already used in XY, but since the Catalog has Categories and is a more visible use I'd lean toward Label instead.
I don't think it would be easily confused with the usage in scripting.

[jacky]

Label would sound best to me, too. It applies nicely, and is usually on a one-to-one basis, whereas categories can have the same n-to-one use in some app.

So, right now the thing is out and it's called "tag" and that's how people are used to it, as well as use it : e.g. tag, {Tag}...
May I ask what's plan for that "conversion" ? Add {TagsID} and a command tags, etc (i.e. plural form) for the new tags, and have the old {Tag} & co be deprecated aliases to the new {Label}, etc ?

[Stefan]

I see this current TAGs as an fluorescent marker (Textmarker)

So how about "Marker" ?

http://www.dict.cc/?s=marker
http://dict.leo.org/ende?lp=ende&lang=de&search=marker

[serendipity]

I vote for labels too.

[j_c_hallgren]

I'd say Label as well....others have given good reasons which I agree with...but there is that issue of conversion...how would that be handled?

[admin]

Label would sound best to me, too. It applies nicely, and is usually on a one-to-one basis, whereas categories can have the same n-to-one use in some app.

So, right now the thing is out and it's called "tag" and that's how people are used to it, as well as use it : e.g. tag, {Tag}...
May I ask what's plan for that "conversion" ? Add {TagsID} and a command tags, etc (i.e. plural form) for the new tags, and have the old {Tag} & co be deprecated aliases to the new {Label}, etc ?

Yes, keep the current tag, {Tag} etc in singular form (deprecated but alive) as synonyms to the new label, {Label} etc. , and use the plural forms for the new "Tags".

[admin]

Okay, this is clearly embarrassing, but it also shows how flexible my mind can be. Thing is: i decided that renaming "Tag" to "Label" and calling a new thing "Tags" is an awful lot of work for me in the changing the code, in upgrading user configurations while keeping backward compatibility, and in updating the documentation. Big confusion, also for users that got used to "Tag" as it is now.

So, I decided to keep "Tag" and "Comment" as it is now, and add the new thing under a different, uhm, label. If you remember, the new thing was a keyword-like additional field in tag.dat, where many keywords can be attributed to a single item, preferably easily selectable from a user-defined set (instead of typing the keyword).
Now, why not simply call the new thing "Keywords"?!?

So, per file, there would/could be:
- One Tag
- Many Keywords
- One Comment

The only unfortunate problem with this nice solution is: there is already a Shell column/field/property called "Keywords". This is currently holding me back... any idea anybody?

[zer0]

I'm not a professional at things like this, but names "Watchwords" and "Stubs" sound intriguing. Granted, they are no match for "Keywords", but to me they have a better ring than the 3 that you proposed. There are probably better ones out there, but my imagination has only taken me this far for now

[j_c_hallgren]

So, per file, there would/could be:
- One Tag
- Many Keywords
- One Comment

The only unfortunate problem with this nice solution is: there is already a Shell column/field/property called "Keywords". This is currently holding me back... any idea anybody?

How about a combination of both: tagword?

Via search, I've found it used mostly as related to advertising based on words found in text of a web site, but it seems to be used by a couple of music player type appl's also...so it's not an unknown word but still flexible enough maybe?

Either that or create your own term! Like XYword!

[jacky]

I vote for the obviousness & simplicity of "keywords". Because it makes sense and is a common term one can assume will be generally understood right away.

Ok, sure, maybe "Keywords" is already a term used elsewhere, so what? Not really a big deal to me, besides if I look on all the fields available to me for custom file info tips, I can see "Tags" or "Comments" listed and I'm pretty sure those do not relate to XY's own features, yet no one complains. So adding Keywords to the mix won't really change much there, if anything it just stays consistent

[serendipity]

I vote for the obviousness & simplicity of "keywords". Because it makes sense and is a common term one can assume will be generally understood right away.

Ok, sure, maybe "Keywords" is already a term used elsewhere, so what? Not really a big deal to me, besides if I look on all the fields available to me for custom file info tips, I can see "Tags" or "Comments" listed and I'm pretty sure those do not relate to XY's own features, yet no one complains. So adding Keywords to the mix won't really change much there, if anything it just stays consistent

Unfortunate that "Tags" is not possible. My vote for "Keywords" too.

[TheQwerty]

I guess I'll be the one with the really unpopular answer. Don, take the time and make the changes.

Everything that uses tags allows many to be assigned, and bucking the convention serves the good of no one.

Using "keywords" instead is going to be confusing and it may well turn away new users who come in with the expectations of using multiple tags per item, search for Tagging, and don't get into the feature far enough to discover "keywords".


I think the discomfort now will be much less than what will come in the future by ignoring the standard, and it will be much more difficult to change then than it is now.

[serendipity]

I guess I'll be the one with the really unpopular answer. Don, take the time and make the changes.

Everything that uses tags allows many to be assigned, and bucking the convention serves the good of no one.

Using "keywords" instead is going to be confusing and it may well turn away new users who come in with the expectations of using multiple tags per item, search for Tagging, and don't get into the feature far enough to discover "keywords".


I think the discomfort now will be much less than what will come in the future by ignoring the standard, and it will be much more difficult to change then than it is now.

I agree fully. I said "unfortunate" previously because tag would be the perfect term. Since Don thinks its a lot of work, I guess its a painful job. Only he would know the cost/benefit ratio of this.