Cumulus uses UIDs to identify the metadata fields since you can’t rely on the field name being unique. The name is also subject to change over time, and can differ between different locales.

If you have the appropriate admin privileges you can can see the GUIDs assigned to the fields by selecting Edit->Preferences in the main menu of the Cumulus desktop client, then choosing Catalog Settings at the bottom of the left hand pane in the Preferences window. This will bring up a page including the tabs “Record Fields” and “Category Fields”. By opening these tabs you will see all of the fields for the currently selected catalog, being the catalog showing in the drop list at the top of the page.

You will notice the metadata fields are in the form of a table and one of the columns is the Field UID.

Now there is a trick you need to know if you want to get a copy of the UID for a field. Obviously it would be a real nuisance if you had to carefully read and type the value, but there is no obvious cut-and-paste function.

The way it’s done is to double-click the Field UID value and this will put it on the clipboard for you to paste into your document. Be careful to click only the UID value otherwise it will open the field properties window, which isn’t what you want.

This little picture to the left of the “Cumulus Sites” page title is called a “Favicon” and if you look really closely at this one you will see that is actually a 16 by 16 pixel picture of a tom cat. Why a tom cat? Because the web server that comes with the Cumulus web clients is Apache Tomcat and this is its logo.

Not everybody wants to have a tom cat icon associated with their web site. It would be better to have a favicon that reflects either your company brand or the purpose of the site. So how can you change it?

There are a number of ways to have your own custom favicon but in order to choose the right approach I’ll need introduce you to the slightly arcane world of favicons.

Favicons were originally invented by Microsoft as a way of visually tagging web sites in the “Favorites” list of their Internet Explorer web browser. Hence the name Fav-Icon. Competing browsers followed suit and effectively adopted this as a pseudo standard. With the advent of the “tabbed” user interface the browsers then started putting the favicon on the page tab as well as using it in other places where the site name is displayed – like the history list, address bar and so on.

W3C subsequently produced an “official” standard for favicons, but only the later browser versions support it completely and Microsoft is still going its own way. This has practical ramifications. For example the W3C standard allows you to use GIF, JPEG, PNG or the Microsoft proprietary ICO format for the favicon image file with an expressed preference for the open standards PNG format. But if you want it to work on Microsoft browsers you need to stick with the ICO format, which is fortunately still supported by the other major browsers as well.

So the first thing you will need to do is produce a 16 x 16 image file in the ICO format. To avoid possible rendering problems on older browsers make sure it has no more than 256 colors. There are lots of commercial and open source programs that you can use and there are even some handy web-based solutions like this one. The browsers also support multi-resolution favicons that look better when a bigger icon is needed such as iPhone links or desktop icons. There is a good article on how to create multi-resolution favicons here.

Now you have your ICO file, where do you put it? The original Microsoft approach was to simply call the file favicon.ico and put it at the top of the site so that it appears just after the host name in the URL, for example http://www.microsoft.com/favicon.ico If you open this URL in your web browser you should see the current Microsoft favicon that appears throughout their site.

While W3C tries to discourage it for various reasons this method is still part of the standard and, importantly, seems to be well supported by all the major browsers. This is in fact the way that the Tomcat favicon is delivered so replacing Tomcat’s standard favicon with your own is the simplest way to change it. So how do we make this happen?

Assuming you have access to the server where your Cumulus web site is installed you need to find your way to the Tomcat directory. Assuming you have the the standard “stand-alone” installation this will be under the directory where you installed Cumulus Sites or Cumulus Web Client. For example in a Windows installation of the current version of Sites the default location is:
C:\Program Files\Canto\Cumulus Sites\apache-tomcat-6.0.20

Under this directory you will find the “webapps” folder in which the “Web Applications” are kept. If you aren’t familiar with Tomcat or similar web containers the concept of a web application (or web app) can be a little confusing, but essentially each web app represents a self contained web process and its web pages are contained within single sub-folder under webapps.

You may not be interested in the gory details so let me cut to the chase right away and say that the file you need to replace is called favicon.ico in the webapps/ROOT folder. In the next section I’ll explain a bit more about what is going on.

Assuming you haven’t changed your Tomcat set up you will see that there are a number of standard web apps  such as docs, manager and examples as well as your Cumulus web app, which will usually be called Sites or CumulusE. To the web browser each web app represents a top level “path” within your site. To understand what I mean I suggest you open your current Sites site in your web browser in a separate window, and then replace the word Sites and everything afterwards with the word docs or manager or examples and see what appears in your browser. Assuming that you haven’t removed those web apps, and they aren’t being blocked by an interposed web proxy then you will be able to view their content.

Now try removing the whole path from the URL so that you only see the server name and possibly the port number. For example: http://myserver.com:8080/ You are now looking at the content from the special ROOT web app. This is why changing the favicon.ico in this folder changes the favicon for the site. Try loading the favicon from your site using something like http://myserver.com:8080/favicon.ico This is a good way to check if you have correctly updated your favicon.ico file.

It can sometimes be quite frustrating checking that your favicon change has actually worked. The first thing to do is run the test mentioned above to make sure the new file is actually being delivered. If it hasn’t changed then try forcing an update by hitting ctrl+F5. If this doesn’t fix it you may need to clear your browser cache and restart your browser – which I’m guessing in this case is probably Internet Explorer. Another possibility is that you are accessing the site through a proxy server which is mistakenly caching the image, in which case you could try running the browser on the same machine that Tomcat is running on.

Having checked that the new favicon.ico is being delivered correctly you can then check if your browser is correctly displaying the new favicon for your site. One thing to watch out for here is that for older versions of Internet Explorer you actually need to put the site into your Favorites list before the favicon is picked up. If your browser doesn’t show the favicon then try clearing the cache and restarting the browser again. You might even feel the need to restart Tomcat but unless there is some strange web proxy set-up this probably won’t make a difference.

Assuming you have got your new favicon working and you are happy with the result you can sign off now. If however you are having problems, or if you are wanting to look at doing it the way that is recommended by W3C then the following may be of interest.

One problem with having a single favicon for the whole site is that it’s the same for all the different web pages or “resources” within that site. This is particularly a problem for Tomcat because individual web apps, which may have quite different functions, look to the browser like they all part of the same web site. Another problem is that in order to enhance performance Tomcat is often “front-ended” by a proxy server that hides away the ROOT directory and any non-public web apps. For these reasons it’s worth knowing that there is another way of setting up your favicon.ico. To do this you need to make changes to the HTML code in your site. If you don’t feel comfortable doing this, or the description below doesn’t make sense to you, then you may wish to enlist the help of a web expert.

The article pointed at by this link shows you W3C’s recommended method. Firstly they suggest adding a “profile” parameter to the head tag so that it looks like this:

<head profile="http://www.w3.org/2005/10/profile">

In practise I have found that this change to the <head> tag isn’t necessary, but it doesn’t seem to do any harm.

W3C then say you need add a link tag in the head section that contains a rel parameter that points to your favicon file. Here is the example they suggest:

<link rel="icon" type="image/png" href="/myicon.png" />

Note that W3C are here suggesting a PNG file for the favicon, but as I said before, to be compatible with Microsoft browsers you really need to use an ICO file. The trick in changing from PNG to ICO format is to make sure you use the correct MIME type, which for Microsoft ICO format is “vnd.microsoft.icon”. Your link tag should therefore look something like this:

<link rel="icon"
      type="image/vnd.microsoft.icon"
      href="/myicon.ico" />

Note that the href parameter can be either an absolute or relative href. In the example above the favicon will be the file myicon.ico at the root of the web site. Alternatively an absolute href may be of value if you want to always use your company’s approved favicon, for example:

<link rel="icon"
      type="image/vnd.microsoft.icon"
      href="http://mycompany.com/myicon.ico" />

For the purpose of having a different favicon for each Tomcat web app the best approach is to use an href that is relative to the “page” being delivered, for example:

<link rel="icon"
      type="image/vnd.microsoft.icon"
      href="images/myicon.ico" />

Before we talk about how to achieve this in Cumulus Sites there’s just one more thing you need to know. It seems that the rel=”icon” parameter isn’t understood by the Microsoft browsers. They prefer to see rel=”shortcut icon”. So in order to stay standards compliant but still keep Microsoft happy I suggest including two link tags, one for each version as I’ll show you below.

Well, that’s the general favicon theory out of the way, now we are going to look at customizing your Cumulus Sites web app so that it has its own separate favicon. You could if you wish zip up the resulting web app to make a “war” file that you can deploy on a different Tomcat server and it will retain its favicon.

Customizing Cumulus Sites is a big topic, and I’ll try to cover it in more detail in later blog posts, but if you follow the instructions below you should be able to make the changes you need.

1. You need to have opened your Sites web site at least once to ensure that the Sites.war file has been unpacked into the webapps folder.
2. If you have already made changes I suggest you take a back up of your Sites directory in case you need to revert back. If you haven’t made changes then the Sites.war file will still contain the original web site.
3. If you haven’t done so already then rename or move away your Sites.war file to ensure that your changes don’t get accidentally reverted back.
4. Inside the Sites webapp folder you will find a sub-folder called customizations. Inside that folder there is another folder called original - this is where the “factory default” web files are found.
5. Create another sub-folder under customizations, effectively making a sibling with original. It doesn’t matter what you call it, but for the sake of this example let’s call it mychanges
6. Copy your favicon file into your mychanges folder. I suggest you call it fav.ico
   
7. Copy the file sites.jspx from customizations to original and open the copy in a text editor and make the following changes.
8. Search for the <head> tag and add the profile parameter as shown above.
9. Add the following two lines after the <head> tag:

<link rel="icon" type="image/vnd.microsoft.icon"
    href="fav.ico" />
<link rel="shortcut icon" type="image/vnd.microsoft.icon"
    href="fav.ico" />

Finally restart your Tomcat server and test to see if your favicon has changed.  If not then you may need to try clearing your browser cache as described earlier in this post.

Further reading:

• http://en.wikipedia.org/wiki/Favicon
• http://www.w3.org/2005/10/howto-favicon
• http://egressive.com/tutorial/creating-a-multi-resolution-favicon-including-transparency-with-the-gimp

The way to achieve this is not well known, and doesn’t appear to be documented, but it is very easy to do.  You only have to add two extra metadata fields called Thumbnail Height and Thumbnail Width then when Cumulus creates or updates the thumbnail, it will automatically store the dimensions in those fields for you.

Here is how you add the extra metadata fields:

1. Open your Cumulus desktop client
2. To make sure you have the necessary privileges I suggest you log in as the Cumulus administrator
3. Open your catalog
4. From the main menu select Edit->Preferences
5. Select Catalog Settings in the left hand pane of the Preferences window
6. Make sure your catalog is the one showing in the Catalog pick list at the top
7. Choose the Record Fields tab and click Add Field
8. Open the Fields tab in the Add Field window (it may already be open for you)
9. Select both the Thumbnail Height and Thumbnail Width fields using ctrl+click
10. Click OK in the Add Field window

Possible gotcha: It’s really important to select the predefined fields from the Fields tab in the Add Field window. If you simply create some custom fields with the same names it won’t work.

Remember that Cumulus only sets the values in these fields when creating or updating the thumbnail, so if you already have records in your catalog you will need to “update” the records as described below:

1. Make sure all of your records appear in your current collection by turning off any filters and selecting Find->Find All from the main menu.
2. Click just one of the records to select it and then select all the records using Edit->Select All from the main menu
3. Select Metadata->Update records->Update now (incl. Contained Assets) from the main menu
4. If you have multiple Asset Handling Sets configured you will then get a pop up window offering you a selection. You will then need to select the one that you want to use and click OK

In Cumulus-speak the term “Category Search” usually refers to searching for records that are associated with one or more categories. Not to be confused with searching for categories in the category tree.

As I mentioned in my earlier article “Categories are not folders and records are not files” you can perform a Category Search in the Cumulus client by simply double-clicking on a category in the category tree. This will replace the current collection (i.e. the records that appear in the collection pane on the right hand side) with a new collection containing the records that are associated with that category.

But what exactly is meant by associated with? I mentioned in my earlier article that records can be “assigned to” one or more categories. So one form of association is this type of assignment. But there is more to it than that.

Unless you have changed the default search settings you will find that when you perform a category search it will also return records that are assigned to any sub-categories, and any of their sub-categories and so forth. In other words it returns records associated with any category in that branch of the category tree.

For example if you have a category tree that looks like this:

animal
-> arthropod
  -> insect
  -> spider
-> mammal
-> reptile

If you perform a Category Search by double-clicking on the “arthropod” category the results will contain all records associated directly with that category, plus all of the records associated with the insect and spider categories. If you perform the search on “animal” then any record associated with any of the above categories would be included in the search results.

In most cases,  particularly when the category tree represents an “is a” hierarchy, this make perfect sense and most people find this behaviour very intuitive.  However, Cumulus is not guaranteed to behave like this. This behaviour is in fact configurable on a per-user basis, by either the user themselves (if they have the necessary permissions) or by a Cumulus administrator.

To better understand this let’s take a look at how it is configured. Please open a catalog in your Cumulus desktop client and then select Edit->Preferences from the main menu. Select “User Settings” from the list at the left of the Preferences window, then select “Search & Sort” and your Preferences window should look something like this:

Default Search & Sort settings

Take a look at the section in the middle that says “Category Search Also Finds Records of” and notice that the check box that says “Categories Below the Selected” is ticked by default. If you were to un-tick this it would change Cumulus’ search behaviour such that only records that are directly assigned to the selected category would be returned. Why not give this a try and see what happens?

You may be puzzling over the other check box that says “and Related Categories“. I plan to do a separate article on related categories so I won’t say too much about that just now. If you can’t wait until then I suggest you look under “Category Types” in your Cumulus client user guide.

Have you figured out what is meant by the check box that says “Categories Above the Selected“? At first this seems a bit confusing but it just means that the search results will also include all records that are directly associated with any parent (or ancestor) category. Remember that it only includes the directly associated records, not those in subcategories of the ancestors.

Did you notice the icons to the right of the check boxes? One of these icons appears at the top of the category pane to let you know which is the actual rule that will apply when you do a category search. This icon (at the top of the category pane) also provides a shortcut to the “Search & Sort” preferences. It’s called the “Search Compass“. Click it and see what happens.

Let’s turn our attention to the section above entitled “Category List Search Finds Records“. To understand what these options mean you need to understand that you can multi-select categories and then perform a Category Search that includes all of them. Give it a try, simply hold down the Ctrl key while clicking to multi select the categories and then release the Ctrl key and double-click one of the selected categories.

So what is going on here?

Well, if you selected the default “Matching At Least One Selected Category” option the results would include all records associated with all  selected categories. Computer programmers think of this as an “or” search, meaning it returns records that match on once category or another.

If you instead selected “Matching All Selected Categories” the results would only include records that are associated with each and every selected category. Programmers think of this as an “and” search, meaning that it returns only those records that appear in each category and each of the others as well. If you think about it this type of search can never return more records than the “or” search for the same set of categories, and will usually return fewer.

The best way to understand this is with an example. Let’s imagine that we have a catalog that contains records that represent images of animals and that these records are associated with the categories listed above in accordance with the animals they represent. Further imagine that some images depict more than one type of animal, and are therefore associated with more than one category.

How do you discover, say, images that contain both insects and mammals? In this case you would use the “and” search as described above for the selected categories “insect” and “mammal“, thus ensuring that you only see records that are associated with both categories.

By contrast how do you discover images that contain either insects or mammals? That’s right, in this case you would use the “or” search – which is in fact the default search mode.

Until next time!

In my most recent blog post on categories and records I spoke about how categories resemble folders. How for example they are organised like folders into a hierarchy that Canto calls the Category Tree and how you can associate Cumulus records with them. I also showed how thinking about categories as being like folders is ok when you first start out, but will very quickly cause confusion and is to be avoided. I also spoke a bit about what Categories are in a technical sense, but I didn’t discuss what they can actually be used for, so I’ll make up for that now!

Let’s start with a working definition:

The word “category” in Cumulus refers to a named entity that can be associated with one or more Cumulus records for the purpose of tagging them for future search and retrieval.

Don’t worry if this doesn’t make complete sense just now as I’ll talk more about it below.

One way to get a “bead” on categories is to think of them as structured keywords. So let’s talk a bit about keywords.

You may already be familiar with the concept of keywords, which are essentially words and phrases that describe a digital asset. Typically a digital asset will be described by a number of keywords. You may even know that a keywords metadata field, courtesy of standards like IPTC and EXIF is embedded in various asset file types and can be edited with asset authoring tools like Photoshop. To save you from having to copy it manually, Cumulus can extract that information from the asset and put it into a special “Keywords” record field for you, and that you can then edit that field to add, remove or amend the keywords that it contains. You can then perform searches on the Keywords field so you can find records in Cumulus, and hence your digital assets.

For many DAM systems, this is as far as keywords go, and new Cumulus users sometimes think that being able to edit and search for them is all they need. But there are problems with this approach, as expressed by the following questions:

• What if you misspell a keyword, or decide that it should be replaced with another keyword? Using a simple Keywords field as described above you would need to visit every record containing that keyword and manually edit each keywords field.
• What if you want to use a “controlled vocabulary” so that only approved keywords are used?
• How do you differentiate between homonyms, for example “ball” the sphere and “ball” the dance?
• How do you capture and represent relationships between keywords, for example how do you express that keyword “Accord” refers to a type of car, specifically a model of car by Honda?

Cumulus categories solve these problems, and more. Let me show you how.

Open up a test catalog in your Cumulus client, for example the Sample Catalog that comes with Cumulus. We aren’t going to make many changes, but may want to make a backup of this catalog in case you want to restore it back to it’s original state later.

Take a look at the Category Pane, which is usually visible on the left hand side of the Cumulus client. If you can’t see it you may need to make it visible by selecting View->Workspace->Category Pane from the main menu.

Unless your Cumulus administrator has deliberately hidden them away from you, you will notice a number of tabs at the top of the Category Pane. These tabs represent what Canto calls the Master categories. If you click the All tab you will see them all listed underneath the catalog name as $Categories, $Keywords and $Sources. If you are using the “Enterprise” version of Cumulus there could even be more of them. I’ll write another blog article to explain fully the significance of these Master categories, but it’s not really necessary for you to understand them now, and for the purpose of this exercise we will just ignore them.

Create a couple of categories by right clicking the catalog name in the Category Pane and selecting New Category from the pop-up context menu. Name them for some common colours, say “Red” and “Blue“.

Now find some records of images that have something red in them and associate them with the category “Red“. Remember you can associate records with categories very simply using drag-and-drop. Then do the same for the “Blue” category. If you have images that contain both red and blue you can associate them with both of the categories.

Did you notice how easy and fast it was to tag the records with the “keywords” Red and Blue in this manner and that regardless of how often you tagged a record you only had to type each keyword once? Isn’t that better than typing the keyword in every time you wanted to make a tag. You’ve also avoided making typos, and what’s more you have a ready-made controlled vocabulary that helps to ensure data entry consistency.

Now what if you later decide that you shouldn’t really start your keywords with capital letters unless they are proper nouns? With Cumulus categories it’s really easy to make this change because you are only changing it in one place. Feel free to give it a try by changing your new category names to “red” and “blue“. To do this just click the name once, wait for a second and click it again, then you can then edit it.

What about creating relationships between “keywords”? This is where the “tree” part of Category Tree comes in, meaning that you can create sub-categories under categories, and even sub-categories under sub-categories. Let’s give it a go.

Create a new category called “color“, then make your red and blue categories become sub-categories of color. You do this by simply dragging and dropping the categories, a bit like rearranging folders on your computer. By doing this you will have created a simple tree that looks like this:

color
-> red
-> blue

In this case the color category is used to indicate what is meant by red and blue, and in doing so can help you differentiate between keywords that are homonyms, being words that have the same spelling but different meanings. For example the word “blue” could also mean “sad“, and you could differentiate the meaning by having them in separate branches of the category tree, for example the other branch could be:

feelings
-> happy
-> blue

But what if you wanted to represent a synonym, being a word that means the same but has a different spelling? For example what if you wanted to have both “sad” and “blue“. Well, the category tree supports that, but it involves an advanced concept called “Related Categories” and that I’ll cover those in a future blog article.

Arranging your keywords hierarchically like this not only helps you during data entry by indicating the correct categories to associate with your records, it also helps you when searching for records by letting you browse the category tree for the right keyword before performing your category search.

If you are already familiar with Cumulus or if you have read my earlier blog post you will know that a category search can also find records in associated categories. By default if you perform a search on a category, e.g. by simply double-clicking it in the category tree, the search result will include all records associated with its sub-categories. For example if you wanted to fine tune your keywords to

color
-> red
  -> magenta
  -> puce
-> blue
  -> indigo
  -> sky blue

This way when you do a category search by double-clicking red you will also^† get the records that are associated with the sub-categories  magenta and puce as well as those that are associated directly with red.

† note: This assumes you have not changed your User settings in Cumulus to make the category search not include the records that are attached to the sub-categories.

I think that’s enough to think about for now. There’s more to learn about categories, so watch this space in the New Year.

In the meantime – all the best for the festive season!

Further reading:

• In your Cumulus “Client User Guide” check out those sections covering “Categories” and “Collections”
• Look on the Canto web site for tutorials about Cumulus categories. At the time of writing there is a good one here

(note that the references to “file manager” below can be taken to mean either the Windows File Explorer or the Mac File Manager)

1. Cumulus categories are arranged into a hierarchy, or “tree”, in the same manner as folders in the file system
2. The category tree is depicted in the left hand pane of the Cumulus client much like the folders in your file manager
3. You can re-arrange the categories using drag-and-drop similar to rearranging folders in your file manager
4. The Cumulus records (representing the assets) appear in the right hand pane of the Cumulus client – just like files do in your file manager
5. You can attach a Cumulus record to a category using drag-and-drop in the same way that files are attached to folders in your file manager
6. When you double click a category in the category tree the records that are attached to that category appear in the right hand pane, just like files do when you double click a folder in your file manager

Canto probably made it work like this because it’s very intuitive for anybody who has used a file manager, and these days that’s pretty much anyone who has used a computer. This file/folder metaphor certainly means you can be up and running with categories and records right away, but therein lies the trap!

The problem is, that if you keep thinking of categories as folders and records as files you will:

• Not understand the subtle relationship between records and the assets they represent, and…
• Not understand the full power of categories, which are one of the great design features of Cumulus, and worse still…
• You will get frustrated with the product when things don’t work quite the way you expect

For example, the record=file misconception causes great confusion when it comes to deleting. In your file manager you will be used to using the delete key to delete files, but if you are new to Cumulus and try this you will get a very perplexing “surprise”. Here a simple scenario that shows what I mean.

1. Open a Cumulus catalog that has some records that are already associated with categories. The Sample Catalog that comes with Cumulus will do.
2. Double click on one of the categories so that the associated records appear in the right hand pane. (A new user will think of this as opening a “folder” with the records that are “in” that folder appearing in the right hand pane.)
3. Select one or more records and hit “delete”
4. Notice that the records have disappeared – in the same way that files disappear when you delete them in your file manager

At this point the new user will erroneously think that they have successfully deleted the records, they may even think they have deleted the actual asset files that the records represent. Neither of which is right.

Continuing the above scenario, double click once more on the category you chose before, and see that the “files” (actually records) have reappeared. A new user would be very perplexed by this and may even be inclined to think that there is something wrong with the product.

Another possible source of confusion, though for some reason new users don’t have the same “what the heck?” reaction to this, is that when you double click on a category it doesn’t show only the records that have been attached to that category. Let’s try another scenario to illustrate this:

1. Open up a test catalog. Use the Sample Catalog again if you don’t mind the fact that you will be messing with it.
2. Create a new category – call it “A”, and then a sub-category under it – call it “B” (A new user will think of this as creating a folder and a sub-folder)
3. Associate some records with category “A” and then associate some different records with category “B” (A new user will think of this as putting the records “in” those categories)
4. Double click category “A” and notice that not only the records “in” that category appear, but also the records “in” category “B”

This does cause some confusion, though most users pretty quickly work out what is happening without having it explained. The folder/file metaphor is so strong however that it seems to survive this experiment unscathed. Probably the new users simply think of this as being like a “super” file manager that shows all of the files in all of the sub-folders.

The problem is that what is really happening is that Cumulus is performing a search on the category and displaying the results, and it’s possible to change the meaning of a “category search” in Cumulus such that different sets of results can be returned. For example you can actually configure your Cumulus such that it finds only the directly associated records, though the default behaviour is to show those in subcategories as well. To make things really confusing for new users you can even configure Cumulus such that the search returns all directly associated records, plus those associated with the higher level categories.  To add to the confusion, you can also configure it to include or exclude what are known as “related categories”. Configuring the category search and “related categories” deserves a separate blog entry, but the point I want to make here is that these more advanced concepts will be hard to grasp if you get stuck in the folder/file metaphor.

Some folks get so caught up in the folder/file metaphor that they miss out on one of the most powerful features in Cumulus, being the ability to associate not only multiple records with a category, but also multiple categories with a record. Stated like that it seems so simple, but many folks struggle to “get” it. All too often I see people creating convoluted category trees with the same sub-categories repeated over and over again, simply because they don’t take advantage of the many-to-many nature of the category/record relationship.

So here are some tips for new users on how to avoid thinking that categories=folders and records=files.

1. Be aware that there can be many Cumulus records created for a single asset file. For example Cumulus can create separate records for the slides inside a Powerpoint presentation, even though there is only one actual Powerpoint asset file.
2. Don’t be tempted to use the word “folder” when referring to categories.
3. Don’t think of records as being “in” or “belonging to” categories, instead think of them as being “attached to”, “assigned to” or “associated with”
4. Don’t think you are “opening” a category when you double-click it, instead think of it as doing a “category search” and be aware that Cumulus can be reconfigured to perform category searches in different, potentially confusing, ways.
5. Try creating some many-to-many relationships between categories and records. Experiment with multi-selecting several categories and dragging them onto the records, rather than vice versa.
6. Experiment with searching for records in multiple categories by multi-selecting several categories before double-clicking.
7. To get out of thinking that the records in the right hand pane of the Cumulus client represent the files in a folder try running a “Quicksearch” and notice that the search results also get placed in the right hand pane. In fact this right hand pane is is really just a collection of records, and there are many ways in which you can modify this collection. That is why in Cumulus terminology it’s called the “Collection Window”.

Further reading:

• In your Cumulus “Client User Guide” check out those sections covering “Categories” and “Collections”
• Look on the Canto web site for tutorials about Cumulus categories. At the time of writing there is a good one here

Until next time!

I plan to make regular posts about DAM, and in particular the DAM product known as Cumulus from a company called Canto. Why this product in particular? Well it just happens to be the one that I know best, having worked with it now for over 10 years.

Although I do sell services and add-on products for Cumulus I don’t intend for this to become a forum for spruiking. I hope that you will find the information here genuinely useful. If you find me plugging my own products and services, then please take me to task!

Over the years I’ve seen a lot of change in the DAM industry, in fact when I first started it wasn’t even called “DAM”, it was called “MAM” for “Media Asset Management” reflecting the fact that in those days the focus was pretty much on keeping track of things like image files. You’ll still see the term MAM around, but these days it refers mainly to that subset of Digital Asset Management that focusses on audio, video and rich media content.

These days DAM systems are designed to handle any type of digital file and there is even a degree of overlap with document management systems in the sense that DAM can also help you keep track of document files.

What are DAM systems used for?

In my experience the most common use is to provide some sort of digital library in which a large number of files are stored or managed in such a way as to allow them to be easily found and retrieved. The idea behind this is that it is cheaper to reuse work that is already done, rather than having to do it again. In this scenario the “users” of the library tend to access it via a web-based interface, and the librarians tend to use what we call a “desktop” application or “client” to administer and update the library. It is possible to do the admin and update work via the web, and many systems, including Cumulus support this, but with current technology the quickest and easiest software to use for this is that which runs on your own computer.

Another common use for DAM is to support the creation of digital assets. For example it can support Desktop Publishing in the creation of layout documents with tools like Quark Express and Adobe InDesign. In this case the DAM system helps the graphic designer find the components from the library, and then tracks the use of those components in the layout documents, and also tracks the layout documents themselves.  It can also provide supervisors with the ability to set up and monitor workflows to expedite the creative process. Then when the layout documents are finalised they can be archived back in the library as digital assets in their own right.

There are many other uses as well, including:

• Brand management – ensuring that only approved logos and images are used throughout the enterprise
• Digital supply chain – the pushing of digital content such as music and videos to retailers and consumers
• License tracking – tracking the use of and granting of copyright and other rights for licensed assets
• Collaboration systems – supporting the sharing and updating of documents and other digital asset between various users

DAM systems can also be integrated with related software such as Web Content Management Systems to provide a single, shared repository of digital assets, rather than each system having its own.

So what do these DAM systems do?

Here’s what you can expect your DAM system to do for you:

1. Fast and convenient “ingestion” functions, by which you can introduce easily assets into the system and have the system extract as much information as possible from the asset itself without you having to type it in
2. Fast and convenient data entry functions, allowing you to perform updates to many assets at once, and to use techniques such as drag and drop to minimise the amount of typing you need to do
3. Support for many types of metadata including tect, dates, multi-choice and so forth
4. Support for metadata standards such as Dublin Core and PBCore
5. Provision of low res “copy proxies” such as thumbnails
6. Comprehensive search functions to allow you to quickly and easily find the assets again
7. Control over who has access to the assets and what they can do
8. Version control of assets, including the ability to track who did what
9. Various asset delivery options, including web and email

Many DAM systems also provide the following:

1. Web based access
2. Usage tracking and reporting
3. Approval of requests for assets and their delivery to the requesters
4. Ability to transcode assets, for example to provide a low res JPEG version of a high res TIFF original
5. Asset transformation functions, such as image editors
6. System integration facilities, including things like import/export, and an “Application Programmers Interface” or “API” to allow access to the internal data and provide automated control
7. Customisation, both of form and function. An API of some sort is really important for the latter

So you can see that there is quite a lot to talk about, and I hope you will find what I have to say to be of value to you!

Until next time!

Glenn Lawrence (AKA “Buster”)

glenn (AT) aimtec (DOT) com (DOT) au