On Fri, 2005-09-30 at 06:58, Anil Gangolli wrote: > There is a wiki page on the Roller Wiki where some of these ideas were > discussed before and maybe this should move back there. > http://www.rollerweblogger.org/wiki/Wiki.jsp?page=BetterWeblogCategorizationForRoller > > I find myself mostly in agreement with Allen here but here is my > personal take. > > With hierarchical categories, I always seem to find myself at some point > faced with the problem of deciding which category is the superior of two > in the tree. Do I organize some stuff as tips/java and tips/linux or > java/tips and linux/tips? Decisions change in the presence of other > related topics at a given level (suppose I add dotnet), and one's > decisions may change over time. Hierarchy is an organizational choice > about the overall space of entries and not really a property of an entry > itself, which is simply that it is, say, both "tip" and "java", whether > I organize that as "java/tips" or "tips/java". > > I concur with Allen that multiple category assignments are further > complicated by hierarchical categories, not necessarily in > implementation but certainly for users. Mostly, this comes from the > expectation that entries in a subcategory belong also to the parent > category. I think combining this with multiple categories makes the > organizational problem even harder for users. > > I* *believe that we can address both of these issues by supporting a > flat ad-hoc namespace of "tags" which users can easily assign to entries > (any number to an entry), combined with a concept of filter-based > folders that use indexes on tags. Folder contents would be dynamic, > defined by search filters on your tag space. > > If you want hierarchy, subfolders can translate into sub filters > (interpreted as conjunctions on the parent folder's filter). For > example a "java" category could be based on a filter for entries with > tag "java" while the subfolder "java/tips" could be defined by the > additional filter "tips" (applied, conceptually, to the result of the > query in the parent folder; in practice this would just be a > conjunction: "tips" and "java"). The same filter "tips" used at the top > level would yield a folder that contains all entries tagged with "tips". > > Filter-based folders would allow you to change the organization, even > flip hierarchies without actually moving/changing anything but the > folder definitions.
i believe this should be inherent to the way we do tag support. any way we allow people to find content via tags should allow for tag intersections. so you wouldn't need to define a special category called "Anil's Java Tips" which is a combination of entries tagged with "java" and "tips" because someone could already get that by using a url like /tags/rss/anil/java+tips > > A few additional comments. > > (1) One may want to distinguish between "global" or "public" tags > (folksonomic classfications) which are intended to make sense in a wide > setting, for example, to match what someone else might be searching for > and which may be useful to sites like Technorati, and "local" or > "personal" tags (personal taxonomies) which are really only for > interpretation in a very local context. People make category names of > both varieties. For example, in my little blog, I use the category > "chow" for food/restaurant-related stuff and "System.out" for > miscellany. These can still be tags, but they are not useful ones, and > may even be confusing ones to use in a public setting. i think this would get way too complicated. i think there should only be a single tag library/index which applies to everything. > > (2) Tags can be more generic attributes than topic. The location-based > tags on sites that Flikr supports are a prime example. I think we > really need to understand these concepts and the types of functionality > people will want to use in the broader setting of blog search and > aggregation. I think such considerations could affect our thinking > quite a bit. > > (3) Ease of tagging is extremely important, preferably these could be > typed as text with some minimal markup right in the entry (as was the > case with my primitive topic tag page plugin). I think this is really > important. Pull downs and selection boxes seem too painful, but I may > be in the minority here. actually, i was thinking of using a simple textfield that would go on the entry edit page just under the title field. then people just enter in 1 word tags separated by spaces. this is how it works on my prototype. the idea being that when you sit down to create an entry you will enter ... a title, a list of tags (if desired), select a category, and enter content. done. -- Allen > >
