Media item tagging functions

[GoogleCodeExporter]

[Describe this work unit]

Complete media item tagging functions so that users can apply keyword tags to 
media items. 

The goal is to have tags similar to Flickr, which is the best tagging 
implementation we have found so far.

Example: http://www.flickr.com/photos/tags/kittens/

I consider it too risky to use the built-in WordPress taxonomy functions 
because they still have many bugs / deficiencies (see the wp hackers mailing 
list), and they are designed for tagging blog posts not huge media libraries 
with thousands of content owners. Future changes to the functions by the 
WordPress dev team could break our plugin. Also, based on a brief review of the 
WP taxonomy implementation, with large numbers of keyword tags across vast 
numbers of items, there could be performance problems.

In my opinion, the best choice *for now* is to provide our own keyword tagging 
implementation, and provide a migration function at a later date, if people 
want it.

===

Completing this feature will require creating a new tagging component. This 
will make the code reusable and separate it from the rest of the plugin.

This will involve:

-Component core, with DB install and component API.
-Database class, with interface code, methods, etc.
-Policy enforcement functions, which control who can tag what that belongs to 
who or what, and allow it to be configured on the admin back end. Similar to 
how we already manage user tagging.
-Template tag functions.
-Updates to existing templates, as necessary.
-Testing
-Documentation   

[What components of the plugin will be affected by this change]
Template files. Admin back end.

[Does this work unit block any other work units?]
No

[Estimated hours of developer time this work unit will require]
15 to 30 hours

[Estimated completion date]
2010-07-21

Original issue reported on code.google.com by CarlRoett@gmail.com on 15 Jul 2010 at 5:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updated info on implementation of keyword tagging features:

General display
===============

-List of tags shown on the item edit screen
-List of tags shown on the single item view template.
-Clicking on tag gives the option to do a global or limited-to-user search for 
items bearing that tag. Mouse hover over item explains what each link does. See 
Flickr link.
-Item owner has the option of clicking an X to remove the tag, just like with 
member tags.
-Tag list displayed in RHS info column, below "extended data". *one tag per 
line* to keep it tidy (as flickr does).
-For owner / authorized users, small form box below tags list that lets them 
add new tags.

-Group list displayed in RHS info column, below "extended data". *one group per 
line* to keep it tidy (as flickr does).
-Need to handle hidden groups
-For owner / authorized users, small form box below tags list that lets them 
add new group hash tags.

Policy
===============

-For *keyword tags* it's the same as member tags, except its one-way. You don't 
have to ask the keyword tag permission when an owner adds it to their item.

-Need to think about other members assigning tags to an item. That's like the 
cross-tagging situation with member tags. Except it's live... we don't need the 
AJAX API finished before we can start doing this.

-Removed tags have to be sticky. If a user removes a keyword tag, other members 
have to be blocked from adding that tag again.

-We're probably going to get a request for a "blacklist" for certain words. 
Flickr lets you tag images with *any* word you want, even very bad words. We can
provide a hook and a skeleton function for filtering, but I do not want to 
waste any time on this.

-Group tags will be implemented as *their own* class and DB table. Because this 
is basically the group albums component and we should not be mixing 
functionality between components.

-For group tags ...first, we should use the # character instead of the @ 
character so people can tell between users and groups.

-Other than that, its *exactly* the same policy logic as member tags, except 
the "friend test" is replaced with "membership in group"

Other
================

-Need to have a cleanup function that changes "new york" "New york" "NEW YORK" 
and "new York" to "New York" and cuts out extra spaces.
-We will store everything as lower case and run a "capitalize first letter" 
filter on them when sent to the template
-Need to update the "Featured content" class to handle 'filter by keyword'
-Need to update the "Media item" class to handle 'filter by keyword'

Original comment by CarlRoett@gmail.com on 16 Jul 2010 at 3:56

[GoogleCodeExporter]

Updated info on why I have decided not to use the taxonomies functions in 
WordPress. This is just from memory, I haven't gone through the code yet.

===

1) WordPress functions are built for categorizing blog posts, not running a 
media sharing or stock photo/audio/video sales site.

Example: user searches for  ("black" AND "puppy") AND ("black" AND "kitten") or 
even just ("black" AND "puppy")

Wordpress can handle "black" as a child of puppy, example 
www.test.com/media/puppy/black, and it could handle the tag "puppy" 
www.test.com/tag/puppy, but it can't do the kind of complex searches needed to 
find a specific group of images in a haystack of 500,000 items ...and that is 
what site owners hosting large media sharing communities or stock content sales 
sites will want to do.

Consider:

"Kittens in Las Vegas"
"Las Vegas Kittens"
"Vegas Kittens"
"Kittens in Vegas"
"Kittens of Vegas"
"Kitten Vegas"
"Kitten Las Vegas"

We want *all* of these tags to be returned for the search ("Vegas" AND 
"Kittens"), so we have to run a full text search on the keyword field. 

-Yes we need to be able to handle multi word keyword tags.

Consider:

"gold mine" (place) and "mine gold" (task)
"car wash" (building) and "wash car" (task)
"player piano" (instrument) and "piano player" (person)
"fire engine red" (color) and "red fire engine" (vehicle)

They mean different things because of the order of the words ...but if we split 
them into single word terms, we lose that meaning.

Also substrings and superstrings of individual terms:

"girlfriend", "girlfriends", "girl friend", and "girl friends" 

...should all mean the same thing in a search. 

We don't want a user to have to enter ("girlfriend" OR "girlfriends" OR "girl 
friend" OR "girl friends")

We want them to enter "girlfriend" and it finds *all* of them.

2) Policy enforcement on tags.

Even if WordPress fixes the search problem (they probably will eventually), we 
still have the unique problem of sites that want the media item owner to 
*approve* keyword tags added to their items by other members, before they let 
the tags go live. If we used the built-in taxonomy system, we'd probably need a 
separate table to store all the tags waiting for approval.

3) Performance

-"Find all the media items owned by 'user X' matching keyword tag 'kitten' 
where the tag is 'approved'" ...is a 5 way inner join using the wp functions. 
Its a 2 way inner join using ours.

-Do we really want to load the *blog* taxonomy table with huge numbers of *our* 
terms. That will slow down the front end of a site when people are searching 
blog posts even though they're not in the part of the site that handles media 
items.

Original comment by CarlRoett@gmail.com on 16 Jul 2010 at 5:14

[GoogleCodeExporter]

One error found. When I clicked on tag, url shown is this one: 
http://mysite.com/media/member/*tag* and redirects to error page. It must be 
http://mysite.com/member/*tag* to see tagged member. It depends on specific 
users slug settings.

Original comment by rollybu...@gmail.com on 25 Oct 2010 at 2:42

[GoogleCodeExporter]

Are you considered searching for some wordpress plugin that already handle 
taxonomy? or some plugin that improve the included wp taxonomy? Maybe there are 
some so we don't need to implement all functions in bpalbum+. Maybe if you 
found some plugin you can modify/improve that or make it compatible/related 
with bpalbum+.
It is just an idea.

Original comment by Any...@gmail.com on 14 Dec 2010 at 10:46

[GoogleCodeExporter]

Probably not. In this case we probably have to write the code from scratch 
because of the level of integration required. Still, if somebody finds some 
open source code that does these functions well, we could certainly take a look 
at it.

Original comment by CarlRoett@gmail.com on 15 Dec 2010 at 1:17