[Tagdb] Single and multi-word tags / swarming and spreading
ogjunk-tagdb at yahoo.com
ogjunk-tagdb at yahoo.com
Fri Apr 14 01:34:09 GMT 2006
Hi, I'm late.
Regarding multi- vs. single-word tags: let people use whichever they want. In other words, allow multi-word tags.
Commas vs. spaces: we all have elementary school training that taught us commas are used as delimiters.
Naive users: that's the majority. If you want to cater to them design your system so they can use it.
For what it's worth:
Simpy allows multi-word tags, uses comma as a separator, and I noticed there are now more IE than Firefox users on Simpy.
Oh, and regarding ranking tag search results higher when tags are closer - Simpy does that, too.
Nice discussion.
Juan - the trust design sounded interesting. Closed source, I presume?
Otis
--
Simpy -- http://www.simpy.com/ -- Tag. Search. Share.
----- Original Message ----
From: Juan Cristian Vera <jvera at blurb.com>
To: Chris Lott <chris.lott at gmail.com>
Cc: tagdb at lists.tagschema.com
Sent: Thursday, April 13, 2006 12:57:13 PM
Subject: Re: [Tagdb] Single and multi-word tags / swarming and spreading
Chris wrote(paraphrased);
- Naive users want multiple word tags more than experienced users.
- Seasoning involves understanding the power of intersections, hence seasoned users prefer single word tags and are happy with the organizational advantages of intersection.
I agree wholeheartedly. I think the core of this thread amounts to two separate discussions:
1. Structuralism: Is it desirable to cater to a naive user's concept of multiple word tags to lower the barriers to access, even if we suspect they will, as they become more experienced users, drop that habit altogether. i.e. should one equate the short attention span, that gives folksonomies their agility in classification, with usage naivite?
2. Boolean logic represented implicitly though UI - What is most intuitive?: here are four SQL statements that result from the same search expressed using the two approaches
a.
select i.header from item i, tag t where i.item_id = t.item_id and (t.tag = "san" and t.tag = "diego" and t.tag = "california")
b.
select i.header from item i, tag t where i.item_id = t.item_id and (t.tag = "san diego" and t.tag = "california")
c.
select i.header from item i, tag t where i.item_id = t.item_id and (t.tag = "san" or t.tag = "diego" or t.tag = "california") group by r.header order by sum(1) desc
d.
select i.header from item i, tag t where i.item_id = t.item_id and (t.tag = "san diego" or t.tag = "california") order by sum(1) desc
3. Metadata: If there is enough richness in metadata captured about an individual tag, there is a lot more opportunity to refine this behavior without the need for multiple word tags. If we tag something as san diego california and the tagging engine captures, for example, the tag instance, the proximity, and the relative order of tags, then a search for "san diego" can return all appropriate results with those that have the tag "san" in front of "diego" ranked higher than otherwise, and those that have "san" next to "diego" ranked higher than otherwise. This amounts to search algorithms and doubtless has side-effects that would need to be considered, but I think it addresses the concern of the implicit AND that may be at the root of the desire for multiple word tags.
best,
Juan Cristián
_______________________________________________
Tagdb mailing list
Tagdb at lists.tagschema.com
http://lists.tagschema.com/mailman/listinfo/tagdb
More information about the Tagdb
mailing list