Tags implementation

[adamw]

Hello,
I think we should agree on some tags implementation :)
My view is the following:
We would have a TagService (in Shotoku of course ;) ), which would manage tag reading/ writing (saving), indexing and searching. The objects on which this service would operate would have to implement a basic Tag interface (with user, date, tag name, resource information), which would be implemented by specific tags: for example, ShotokuTag to tag a file in svn (this would additionaly have a repository id), or a HttpTag, to tag an arbitrary page or some other tag when we have other great ideas.

The TagService could also synchronize tag info between the DB and SVN, or with the web site Damon showed us but I forgot its name.

What do you think?

--
Cheers,
Adam

[szimano]

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.

[szimano]

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.

[dsicore]

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.

[adamw]

Hello,
What Damon wrote is almost exactly what I meant :). (However Damon's text is more "conceptual" ;) ).

I agree that the tag ends as a string, but I wanted to have a TagObject so that we - tag users in development - can operate not on strings of the form "user:tag:date:etc", but on a handy object where you can do tagObject.getAuthor() :). This would of course have an appropraite toString() method and a String-based constructor.

And yes, we would have "TagProviders" as Tomek called them - like Damon wrote - one for Shotoku, one for URLs, maybe some others ;).

What is important is also the direction of synchronization. It can be either DB --> Shotoku or Shotoku --> DB. I would personally opt for the first one (it can be easily made to work reliably) because of speed.

[dsicore]

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.