[drupal-devel] Core Folksonomy: First Code Available

[Morbus Iff]

> Let's try and pull this together.
> 
> - Use taxonomy tables. With two additions:
> 1) Add a UID field to term_node.
> 2) Add a flag on vocabulary. "Folksonomy"

Right. These changes have already been patched out and are in my sandbox. 
Per the install instructions in the README.txt, you should be able to:

  * Run updatedb.$DATABASE against your current HEAD installation.
  * Patch your modules/taxonomy.module per the provided patch.
  * Create a taxonomy as normal; notice the new "community" option.
  * Test out a few nodes and created-terms from this taxonomy.

I chose "community" INSTEAD OF "folksonomy" per the following reasons:

  Next up, we modify the vocabulary table with a new "community" column.
  This column determines if we should display a taxonomy selectbox or
  input box on the associated forms, as well as how we should expect
  our user-chosen terms to be sent to us upon submission. The name
  "community" is intent-focused, as opposed to "is_folksonomy" or
  "default_ui", arguably more descriptive, but also more breakable.

> 1) Taxonomy_form needs to provide a choice of input field depending on 
> the folksonomy flag. If it's turned on then it uses a form_textfield 
> rather a form_select for each folksonomy vocabulary that is valid for 

This is already done. Have you seen my patch and UI?

> 2) _save() needs to iterate through the returning comma delimited 
> strings from the new text fields. It splits them, cleans them up and 
> then creates new entries in term_data if needed. This will need some 
> helper functions to convert from comma string to clean array of 
> tids/names and back again.

This is already done. Have you seen my patch and UI?

> 3) Term display and edit is turned off in admin_overview for folksonomy 
> vocabs. This is optional and is waiting for a better way of displaying 
> and editing the expected very large numbers of terms in a folksonomy 

Per my TODO, I'm planning on experimenting with turning the current 
vocabulary display into a pager display, similar to all the other "lots of 
data" menus within Drupal. To ensure that the hierarchy is still visibly 
noticable across multiple pagers (where the parent could be on one page, 
and the child on another), the full hierarchy will always be spit:

Instead of:

   Parent Name (edit term)
    Child 1 (edit term)
    Child 2 (edit term)

The planned pager display will become:

  Taxonomy/Term         |        Operations
  -----------------------------------------
  Parent Name/          |          edit
  Parent Name/Child 1   |          edit
  Parent Name/Child 2   |          edit
  Folksonomy            |          edit
  Folksonomy/Cat        |          edit

and so on.

Regarding the rest of your stuff, all good,
and all stuff I haven't yet thought about.
Minor comments below.

> 4) The term display on nodes is improved so that terms from vocabs are 
> grouped by vocab and have an optional vocab name before them. Hidden 

Less a folksonomy issue and more a taxonomy bug. I'd consider making a new 
Issue on this and patching it independently of our folksonomy work.

> text links are added to provide technorati with something to scrape and 

This should be entirely optional. I'd never want this on my stuff.

> 5) A hook in the save() code populates term_relation to provide "tags 
> like this one" cluster analysis and navigation.

I won't be working on this.

> 6) A hook in the _form_all() code makes it easy to extend the $help 
> description with suggested terms from Most used terms, My terms, Related 
> terms, Synonyms and anything else we think of later.

Hmm. I'm not sure about this. I see the $help stuff as "help about the 
Drupal feature" instead of "help about choosing the right tags for this 
site which just happens to be using Drupal".

> 7) Contrib modules get built that add things like a Most popular terms 
> page, All terms page, a block for navigating related and my terms for 
> the current term page, links to technorati and so on.

Right - this is where my (planned) taxonomy_similar module comes in - 
it'll allow the user to visually choose similar keywords "better" than the 
ones he may have previously chosen. Or, he can just ignore it and close 
the browser immediately. Your "links to technorati" in this "Contrib 
module" item is the solution to my concern above ("make technorati links 
entirely optional").

> 8) Work is started on "nice" URLs for taxonomy category pages. eg

I've still not figured out the perfect way of implementing this.

-- 
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