[drupal-devel] Folksonomy: No taxonomy.module Changes / URL Design

[Morbus Iff]

Ok, apparently. I'm starting on this "now", even more sooner than before.

I've named it folksonomy_shared so as not to interfere with the existing 
folksonomy.module API by Moshe. I've dubbed it "shared" as it is the key 
term that distinguishes it from the future direction that Moshe was 
thinking (per-user-vocabularies). I confess to not really knowing the 
direction that jbond wants to head in. And, unlike awTags (which, at face 
value, seems to do most everything I need), folksonomy_shared tries to 
integrate as tightly as possible with the existing Drupal taxonomy. This 
gives me the benefit of RSS feeds (an absolute requirement), as well as 
using synonyms to store similar keywords.

  * I've started a sandbox for this: sandbox/morbus/folksonomy_shared/
  * Only one database change is needed: adding a uid to term_node.
    http://lists.drupal.org/archives/drupal-devel/2005-03/msg00422.html

This morning, I took a look at all the places in taxonomy.module that used 
term_node, so as to properly handle the new database addition above. At 
first glance, I don't see /any/ place that requires changing:

  * The most important thing that distinguishes a folksonomy from a
    taxonomy ISN'T the I of UI, it's the U. As such, when looking
    over term_node mentions in taxonomy.module, there were no places
    that I felt REQUIRED the addition or understanding of the uid.
    For a "taxonomy" (or, really, a "controlled vocab"), the uid
    is irrelevant. All normal taxonomies would log the uid as 0,
    with no change to the existing code.

  * taxonomy_node_get_terms_by_vocabulary "finds all terms associated
    to the given node, within one vocabulary." This would seem to be
    the most immediate and obvious place to include the uid code
    ("here are all the terms applied to this node, and here are
    the people who applied them"). But doing so here would be a
    bad idea: it'd unnecessarily complicate the code (especially
    when you think about the $key), and ultimately overload the
    meaning of the function name. Same with the regular _get_terms.

  * taxonomy_node_save doesn't need to be modified. Without the
    uid specified, it'll default to 0, which is a proper value for
    non-folksonomies. folksonomy_shared would save its values with
    folksonomy_shared_node_save on a nodeapi 'save' hook.

  * taxonomy_term_count_nodes wouldn't need to be touched, because
    the number of nodes with a term cares little for uid assignment.

  * taxonomy_select_nodes would be handled with a folksonomy equivalent
    version which would allow tids and uids to be passed as params.

One of the next usability issues I've been thinking of is URLs, and I've 
been having some conceptual issues of how to get them right. Your comments 
will be heartily appreciated. The following are known possibilities:

  drupal.org/taxonomy/term/34
  drupal.org/taxonomy/term/$tid

  del.icio.us/jagbot
  del.icio.us/jagbot/origami
  del.icio.us/origami
  del.icio.us/$uname
  del.icio.us/$uname/$term
  del.icio.us/tag/$term

  autowitch.org/tags/861
  autowitch.org/usertags/1
  autowitch.org/tags/$tid
  autowitch.org/usertags/$uid

I heartily agree with jbond: the URL should use $term, not $tid. The 
problem is that it becomes an either/or situation. Drupal prefers using 
the $tid (see the first example above), but there's no way to distinguish 
a $term of "1984" or "666" or "101" from the $tids of the same value. So, 
using $term is arguably "more" folksonomish, but breaks Drupal tradition.

The current format I'm thinking of implementing is as follows:

  /folksonomy/1			# show all tags in vid 1
  /folksonomy/1/term/hello	# show all tags in vid 1 for "hello"
  /folksonomy/1/term/1984	# show all tags in vid 1 for "1984"
  /folksonomy/term/hello		# show all tags in any vid for "hello"
				# see below for my concerns on this one.

The problem with the above is two-fold:

  * if we want to support multiple folksonomies, the $vid needs to
    be part of the URL. Otherwise, there'd be no way to distinguish
    which "hello" from which $vid we'd like to look at. The current
    taxonomy doesn't do this because we always have the unique $tid.
    But, if we're going to put $term in the URL, we need a further
    bit of information to properly assert it. Using the path module
    would have a similar problem.

  * if we're using $term and not $vid, why not $vname?

As for users, I'm leaning toward:

  /folksonomy/user/41/1		   # show all vid 1 tags for user 41
  /folksonomy/user/41/1/term/hello  # and so on and so forth. I feel
  /folksonomy/user/41/1/term/1984   # like these URLs are horrendous.
  /folksonomy/user/41/term/hello

The most immediate problem is, again, the lack of standards. If we're 
using $term and not $tid, why shouldn't we use $username and not $uid? The 
URLs become even worse and sometimes broked:

  /folksonomy/user/morbus/1
  /folksonomy/user/rogue_githyanki/1/term/hello
  /folksonomy/user/killes at www.drop.org/1/term/1984
  /folksonomy/user/ohmygodicantdecidemyusername/term/hello

Help! This design is the next big hurdle in my head.

-- 
Morbus Iff ( you are nothing without your robot car, NOTHING! )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus