I agree but i don't see the point of having different tags then shotoku... why don't we do this like every contentmanager has it's own tagging way ?

Or you plan to add ability for adding other let's call it TagProviders... so... i can for example add some functionality to add/removing tags in wiki and this taggingservice in shotoku will be just one resource for addding/removing/getting tags in multiple tagproviders (wiki, svn, forums etc.) ?

If yes... i still don't get why do we need Tag object... isn't tag just a string ? some content and user that've set it ?

the site is http://del.icio.us/ :-)

T.

I've been talking with Christoph Drieschner about his tagging experience (he did metajizer and now he does tagging of current content we have at jboss).

See the links:
http://labs.jboss.com/wiki/Metajizer

and

http://www.openrdf.org/ (this is what they use for stroing data)

T.

Yes, the tag service will be required in Shotoku, however, I'm not sure it is a function of a "Tag" per se. It really is a piece of metadata associated with a node. The concepts that apply here is really the ability to search and index the metadata properties associated with nodes in any given CMS implementation (i.e., JCR, SVN, File, DB). The CMS implementation Shotoku is referencing must have the ability to accept properties on Nodes.

As Adam stated, we need to index the metadata (i.e., the cms <-> index sync). The indexing service must accept general notions of properties on nodes and provide a reasonable API for the aggregation of nodes based on queries of properties.

Also, the construct holding the "Tag" will likely be of two types:

1. A Tag associated with a Node in a Shotoku managed CMS
2. A Tag associated with a URL, which can be anywhere, including other domains outside of Shotoku's realm.

This means the indexing must include:

1. The User
2. The source of the data (i.e., which CMS) if available.
3. The URL
4. The tags (i.e., properties) to be associated with Node and/or URL.

With regards to del.icio.us (hereafter refered to as "D" because I hate typing that string), we will definitely integrate with such systems and provide information into them and other types of tagging systems; however, what will be the biggest gain is the up front presentation of the mechanisms to subscribe to tagged content on Shotoku-aware systems such as jboss.org and the ability to tag without a special interface other than what is in front of the user. This means we need to determine the best way to integrate with D and other systems with regards to user management (i.e., how do I get Adrian's D user info to push information into D as him?).

Adam, another thing, you mentioned a "TagService" and a "TagObject" I would think "TagObject" would be characteristics of Nodes in any given CMS. For example, the Node.setProperty() would be the mechanism. However, the "TagService" might have a tag object. Maybe you are abstracting away from the ContentManager a bit, and I'm missing something.

Tomek is already complaining about speed, but I think the syncrhonization will need to be two directions... db -> shotoku and shotoku -> db. Obviously, the web based tagging operations will update the db first for performance unless you can provide an asynchronous property update.