• What tagger is up to

  last modified November 9, 2006 by whit

reporting out on the tagger project



11/9


got initial install of tagging up on http://dev.openplans.org.

and some reaction archived at tagging ui .



<<< what engineering is up to | folksonomy / taxonomy | planning >>

11/7

done:
1. cleanup: returning the test page to the way it was before
yesterday(moving new test to new test-view)

2. link tag links to tag browsing pages

4. make tagger use member UID rather than login name as "user".
disambiguating generic tagger.annotations_by so items, users and
tags will never be mistaken as something else.

5. tagview page now displays the other tags of content that matches the currently-viewed tag

7. point "tagview.html" links to a site local url ala portal/tag/

3. display other tags with links inside the browsing ui

on deck:

5. beautification tagger beautification list

6. cross browser checking css/js
(my tag input is still cut off and the smallest text in the cloud is
unreadable 1280x1024 Mac)

8. adding a simple tag search(gravy) on tags page.


11/1/2006

after some thrashing due to miscommunication, the fog clears.

Josh has created an new project for the opencore specific pieces for tagging and moved install and skin changes into it. With a working install, Whit is able to see all that got done last week.

we now have some basic working ui, including a nice new js feature added by Novalis to augment tags(a way for users to "add" an annotation that is the same "tag" as an existing annotation). the guys reworked the tagging widget a bit and we've talked a little about reworking it a bit more.

  1. fix: after a tag is deleted, widget stops working
  2. fix: make text size inside tagging input readable
  3. rework: make "me too" tagging a "+" button
  4. rework: make links go to tagview (or display dynamically?)

iteration task's left:

  1. UI scrub up(see list above)
  2. Project Tagging: On monday, we discussed how to handle the fact that the content view for a "project" is also a separate piece of content.  We decided that while content appeared as the homepage, both the project and the content would get the tags, thus mitigating confusion caused by having multiple tagging interfaces in one page(defer).
  3. See Your Tags(ie tags you have used on the site):
    Ethan and Josh wrote a "getTags" style routine for generating tags that belonged to a user.  If member folders had an interface, it would be possible to create a view that used the existing UI machinery to display the users tags.   we also have a small ui issue with similar to "project tagging".
  4. Browsing
    Need to display other tags for a piece of content(another metadata column)
  5. Searching
    Browsing is the main deal, but jackie would like searching.  Usually this mean intersections of either (all or mine) & (tag1 & tag2 & tag2).  Need to do a little investigation about  whether we want to do this straight in the catalog or with rdflib(using the catalogs metadata).

On the technical side, we need to investigate upgrading ResourceRegistries so we can register zope3 resources as cacheable scripts and css.


10/23/2006

On Friday ethan, robert, and josh got started on tagger integration into the openplans site by sticking the basic cloud and basic widget into the 'richdocument_view.pt' in OpenPlans skins patches.

Today, david and chris are going to work on getting cataloging hooked up and some listing views for tags.  Josh and Ethan are going to clean up the UI work started yesterday.  I'm going to polish up the

10/20/2006

w: last night sent out 2 emails to dev, one detailing how a group could get started and priorities, the other detailing higher level tagger architecture in relation to browsing.

w:working to get tagger's plone install working and some simple catalog subscribers for the tagging widget. To prototype what this event subscriber will do, I'm using the zopectl debug command line.   From python, this is a how you tag a piece of content w/ python.

>>> from rhizome.five import site
>>> site.initializeSite(app.ZT, sethook=True)
>>> from tagger.zope2.site import get_tagger
>>> tgr = get_tagger(app.ZT)
>>> fp  = getattr(app.ZT, 'front-page')
>>> tgr = get_tagger(app.ZT)
>>> tgr.tag_item(fp, 'whit', ['salad'])
set([('salad', u'kDNzZspb7')])

>>> from tagger.plone.interfaces import ITagList
>>> ITagList(fp)
set(['salad'])


10/19/2006

Architecty
Thinking about the browsing needs requested by the customer, whit made a diagram to mentally prototype how this system may work: topp tagging diagram

The general idea here is to contstrain searches by a triple defined by each tagging utilities context, but store all data in a central rhizome store.  This will require a new tagger utility class that will wrap each search and entry call with the context specifiec triple to use for filtering.

The crux of this work is focussed on the utility, so it's non-blocking for the ui stuff.  current widget should work regardless.

Tagger Development Setup instructions
How to get started developping tagging for Openplans.

9/25/2006

DWM got magicbronson set up with his local machine and copied install instructions for posterity.  magicbronson digs into tagging widget. DWM commits fix for nested tagger instances.  DWM sets up jsondoctest and drops calvinhp a line about TextIndexGraphs(so we can hook up autocomplete?).

Things to look at: azax/kss(for adding tagger to ui).  simple search return pages. syncing with other social bookmarking apis(promulgating and harvesting tags).

Ideas: adding tagging to wicked.  adding filters to tagger for tag returns.