Arguably, the single most powerful feature in Cumulus is the category. Sure, the ability to have hierarchy trees (taxonomies) isn't unique to Cumulus, but it's all about the metadata! More specifically, it's all about the category metadata inheritance! Canto provides the inspiration for this crazy-why-didn't-they-think-of-it-already-feature from their Category Permissions functions.
Structural Elements to The Cumulus Catalog
To understand this I want to back track a little and discuss the Cumulus catalog a little. If you think of common Relational Database Management Systems (RDBMS) like MySQL or PostgreSQL, the idea is that DBs are comprised of multiple tables and those tables can usually do have relationships to other tables in the DB.
Ok: Now back to a Cumulus catalog. At the basic level there are two main tables in the catalog: records and categories. Relationships are formed between the two by assigning records to categories. (If you wanna get über particular, you're not actually assigning the record to the category. You are in fact, doing the reverse: Assigning the category to the record.)
Because categories are in a separate table and each one is uniquely tracked, you can attribute metadata to categories, just as you would to asset records. (The functionality thereof is limited in the Workgroup Edition; this is all based around Enterprise Edition or the add-on for Workgroup.)
Cumulus already adds metadata to category fields. It's what lets the application know a particular category is a $Source vs Normal vs related. In the context of a $Source category, Cumulus creates values for the "folder reference" just like it does for records via the "asset reference" field.
It's the ability to have user-defined metadata models in the category table that makes the feature so powerful, if a bit abstract at first. When I first started to think about category metadata, I was confused about why I would want to assign metadata to them. I mean they were already convienent continers for records. What else could you want?
- The BookTittle
- Front matter
- Title and Copyright page(s)
- Table Of Contents
- Product reviews
- Equipment reviews
- Back matter
- Front matter
You could setup a category field "Project Type" and assign a value "Book" to the book title category. Next you may have a field indicating a particular category is a chapter or not. And lastly what type of content a category represents in the hierarchy. (Recipes, product taste tests, equipment reviews, and so on.)
You may even want to track other information about your cook book in category metadata like ISBN, ISSN, publishing date, etc.
When it's all setup and tagged your poised for some crazy granular and powerful search options. Think about a search link this: "find equipment reviews from cookbooks published in 2012". I know, pretty awesome, huh? Except for the catch... and there's always a catch. All of that metadata has to be explicitly tagged for each sub-category in the tree.
Well that's just a PITA!! Compounding the problem is that, at the time of writing, Cumulus does not have a "Category Metadata Template" feature (that's a blog rant waiting to happen, btw). It now becomes a rather expensive proposition in terms of time, and resources to tag each category explicitly. Some poor schmuck (usually me or somebody on my team) has to tag each and every category chock full of explicit metadata. Now if there was only a better way... Oh, wait: there is!
Category Metadata Inheritance!
Canto actually has implemented the foundation for the model I'm proposing in the way they deal with Category Permissions. When you set permissions for a category node in the tree, you have options on how the permissions are propagated to the sub-category nodes. By default, the option in Cumulus is set to "Copied from this Category". Or, in other words the permissions are inherited. You can choose to override the inherited permissions of a particular category and set explicit permissions at any time. This is also idea should be familiar to anybody who's dealt with Operating System permissions (Think NTFS, POSIX or ACLs.)
Now if you applied this to metadata at the category level, you have an amazingly powerful method to fill values down the tree. From my book example above, Instead of explicitly tagging every sub-category with the ISBN, one would enter the ISBN in the parent category for the project.Then tell Cumulus to have sub-categories inherit the value. In a departure from the Canto Category Permission model, Inherited values would not be set explicitly. Instead I envision some sort of UI element, to indicate the value displayed is inherited. There should be a way to propagate the value down the tree. Propagating the value would would provide an option to set it explicitly or become an inherited trait of the parent node. At any point in time inherited values can be converted to explicit values.
I think a smartly-implemented category metadata inheritance model could take Cumulus Categories beyond powerful to full-on killer feature. Granted not every customer would use it, but for ones that rely on category metadata extensively it could really be a game changer.