As you all know, CQ5 supports tagging and taxonomies and both side by side. Taxonomies are great, because they allow multi-dimensional classification of content, but sometimes there are things that do not fit into the taxonomy. And this is where it comes handy that you can just type and add a new tag to the standard tag namespace folksonomy. Using this feedback from the folksonomy you and enhance and improve your taxonomy. But what happens if you do not start with a neatly organized taxonomy, but with a wild-west folksonomy that has been created by numerous authors and you want to bring order into the chaos?

Actually, you are in a very good position. Starting with data first, gives you the ability to come up with a meaningful taxonomy that is relevant to your content in the first shot. Using a folksonomy as a starting point to create a taxonomy is what I (and others) call "Folksonomy Mining". As an illustration how to use my Folksonomy Mining technique, I will be using the folksonomy created by the last.fm community.

1. Start with a folksonomy of viable size in a well-defined domain. You need at least 1000 tagged items and the domain should not be all-encompassing like "web pages on the internet". The last.fm folksonomy is certainly the right size and with music we have a domain model that is restricted enough.
2. Get 100 most popular tags out of the folksonomy. With CQ5 tagging you have the "count" column that says you how popular a tag is. With last.fm, there is an API method for that. (100 tags)
3. Remove obvious duplicates. "favorite", "favorites", "favourites" and "favourite" for instance need to be merged.
4. Create dimensions for groups of similar tags. Examples that I can find in the last.fm folksonomy are: time (60s, 70s, 80s, 90s, 00s), origin (american, australian, british), mood (ambient, atmospheric, chillout), vocals (female vocalists, male vocalists, instrumental), ownership (albums i own, seen live), origin (soundtrack, covers, live, remix), season (christmas, summer), preference (amazing, awesome, beautiful)
5. There is usually low co-occurrence between different items in the same dimension.
6. For more complex dimensions such as genre (rock, pop, country, folk) you might want to create sub-and super-categories. For example rock-metal-death metal-brutal death metal (yes, this is part of the top 100)
7. There is usually high co-occurrence between super- and sub-categories. And the super-category usually has more entries than the sub-category.
8. Fill in "holes" in the taxonomy. For instance the time dimension: add 30s, 40s, 50s. In the season dimension add: spring, fall, winter
9. For categories with many sub-categories add grouping categories where they become helpful, for instance in the origin dimension it might help to add american, european, asian, african to group origins.
10. There will be a number of tags to remain uncategorized, just leave them this way, and leave the folksonomy open, so that new tags can be added over time

With these ten simple rules you have managed to grow trees out of the tag cloud, added structure where needed that can be re-used in query builders and other places of the system.

Today, our CQ5 Digital Asset Management and CQ5 Social Collaboration become available with the launch of CQ 5.2. This is a great day for me, because my two products that I have been working on for the last one and a half years are going to market.

Both with CQ DAM 5.2 and CQ Social Collaboration 5.2 I have been standing on the shoulders of giants, which have enabled me to implement a bold vision of Digital Asset Management and Social Collaboration integrated into Web Content Management in such a short time, following our CQ5.1 release last November. These giants are our developer team and our product marketing team who have a done a marvelous job on getting this product to countless demos, POCs, beta projects, press and analyst briefings and who have implemented one cool feature after the other.

But standing on the shoulders of giants also means reusing a great platform to build upon. We did not have to think a single second about clustering, backup, scaling, permissions, LDAP integration, workflow, development environment, because all this is at some level provided out of the box by CRX (and its underlying Apache Jackrabbit and Apache Sling foundations) and the CQ5 Platform we share with CQ5 Web Content Management.

I would like to take the opportunity to shed the light on two smaller features, one in CQ5 DAM and one in Social Collaboration that we typically do not include in demos, but that offer a huge potential for everyone who sees our products as a platform to realize his own ideas.

Feature number one is the workflow launcher we are using especially for CQ5 DAM. This workflow launcher will listen for repository events at a certain part of your content repository, for example the DAM bulk upload hot zone or a Sharepoint repository we are monitoring through our connectors. Once a new file is being created here, we launch the workflow that will take care of the actual processing. For the end user this means: more flexibility in creating complex workflow-driven processing solutions for digital assets. And it means a reduction of magic, because everything that will happen to your assets is visible (in the Workflow Models tab) and the reason why it happens is visible in the workflow launcher tab. Not attempting to do magic and to appear as magician should be a goal for every software engineer.

The second feature is even less graphic (guess why we are not demoing it), but it is one of the small pieces that makes Social Collaboration so great. We call it the 'Feed Importer', but it actually does a lot more. The idea of the feed importer is to poll a remote resource at a specified interval, to parse it and to create nodes in the content repository that represent the content of the remote resource. We are using this at two places right now - for subscribing to remote iCalendar files just like you do in Apple's iCal or Google Calendar and in the blog, where you can aggregate existing blogs in one 'planet blog' that for instance contains all bloggers of the JCR community. This auto-blogging-feature has been in the blog since Advanced Collaboration 1.1, but with Social Collaboration 5.2 there is a proper and powerful API that can be used in customer projects as well. Needless to say, in order to implement a new parser & importer all you have to do is implement one OSGi component and I expect it to be not too long till we see Twitter-mashups on CQ5-powered websites that are using the Feed Importer.

So thank you very much for all the help with the 5.2 release and I am looking forward to see many CQ5-powered community websites and public asset repositories soon.

These are the top ten reasons why you should use tagging in CQ5:

10. CQ5 is great when dealing with structured information thanks to the nesting of pages and paths. It is also great when dealing with unstructured information thanks to the built-in full-text search. Tagging allows you to combine the strengths of structure and flexibility.

9. Tags have many names and faces: tags, taxonomy terms, categories, labels and many more. They are flexible in their content model and flexible in the way they can be used, for instance for outlining target demographics, categorizing and rating content or to create a secondary content hierarchy.

8. Tags can be created by anyone who needs a quick way to annotate a page. This helps you with search-engine optimization, as tags will automatically show up in the meta-tags of the page, and ensure your page will be found by search engines.

7. Tags combine Web Content Management, Digital Asset Management and Social Collaboration. The tagging system is a core component of CQ5 and it is used by all CQ5 Applications to categorize content. Additionally it is available to developers for their own tagging-enabled applications.

6. Tags can be simple and sophisticated at the same time. To create a tag all you need is a word and the touch of a button. That's simple. But afterwards you can add a title and description to it to add more semantics. There are no limits on the labels you select for your tags.

5. Tags improve your search experience. You can search for tags and for content that has tags. This is used in CQ5's default search component, so your users can drill down to see only the results that matter in the search result pages.

4. Tags powerful organizators. With the ability to create tags and sub-tags it becomes possible to express whole taxonomic systems of terms and subterms and their relationships. This allows you to create a second (or third) content hierarchy next to the official one.

3. You can never have too many tags. And if you have, you can create namespaces to sort and organize your tags. With namespaces you can make sure that tags that belong together are together and create categories of tags.

2. Tags can be controlled. With all the flexibility and simplicity of tags, you have still full control over all your content. Apply permissions to tags or namespaces to control who can create or use your tags.

And the number one reason why you should use tagging in CQ5 is:

1. Tagging makes your life easier by giving you a better way to organize content without too much thought.

Calling all bloggers that cover content-centric applications or content-related topics: if you would like to get added to the blog aggregation contentcentric.org(*) please drop me a line at ltrieloff(at)day(dot)com. I would love to hear from you.

(*) contentcentric.org is an aggregation of blogs of the content centric community. This includes Java Content Repository, Sling, and content centric applications like Content Management Systems, Blogs, Wikis.

My approach to learning a new technology (or-relearning something that changed several times since I last spend time with it) is writing documentation. As I wanted to write a small Sling application using the newly released Apache Sling 1.0, I decided to create a one-page documentation of the Script-resolution process in Sling. This is the frontside of my cheat sheet. It shows you how to get from HTTP request to content node, from content node to resource type, from resource type to script and what scripting variables are available.

On the flipside of the cheat sheet I documented all the hidden, but powerful request parameters you can use when dealing with the SlingPostServlet, the default handler for all POST requests that gives you endless options for creating, modifying, deleting, copying and moving nodes in your repository.

Click on the thumbnails to get a high-resolution PDF version of either side (3,7 and 1,7 MB) or download the PDF version (300 KB) here.

cheatsheet.pdf