flagge deutschlanden


2. How do you manage files most efficiently?

If you want to improve data storage and workflow in the advertising and marketing department of a company, you often hear that the hierarchy of folders and files is "perfectly adequate". Such resistance is normal, for in the past typewriters, stagecoaches and a conception of the Earth being the center of the universe were also "perfectly adequate".

What Apple brought onto the market in 1984 – the graphical user interface with the analogy of folders and documents – is now already more than 30 years old and has long been established on all other platforms. Operating systems, however, are schlepping around a concept that is even much older: the strict hierarchy of lists and files, dating back to the "Multics" operating system whose development began in1964 That is not a particularly fresh, new idea, but one of the oldest in computer history. Back then, science fiction authors at best devoted time to thinking about everything you could do with computers in the future.


This strict hierarchy has its advantages, but not just only advantages. It is relatively easy to think up a folder structure that logically represents a hierarchical order.    

A lot can be said about products, and that from the different points of view of the various departments:

Marketing looks at price, target group, appeal, presentation, competition.

For a design engineer, a product, as a rule, is primarily its technical features: Size, weight, performance. The industrial designer is interested in information about the shape, color and haptic of the material. The businessman is interested in buying and selling prices and discounts. The product manager knows a thing or two about each of these areas, as do those responsible for sales and the online shop.

The bad news: All those departments input the same data independently from one another into their systems – that is redundant data entry, and it costs a lot of time and money.

Here is where the topic of product information management (PIM) comes into play: All this data is merged in one system and kept up to date for connecting to other systems respectively via interfaces. Being able to take over data about products from other systems, for instance, instead of entering it two or three times is clearly helpful and one of the strengths of cavok. You will appreciate the flexibility of our system in this regard since you can connect cavok either with a PIM system as the central place for product data or individually with other systems in the company for the given situation, depending on what makes more sense for your company objectives.

cavok Metadaten EN

Metadata is a more flexible concept than pure hierarchical management.

A modern DAM system is based on metadata in a relational database. One or many files can be allocated any number of fields with any content. This makes it possible to work beyond the boundaries of a hierarchical file system. With many DAM systems, though, you quickly come up against the limits in this event, especially if you have only the narrow scope of IPTC/XMP fields available to you. One of the biggest strengths of the cavok system is that each metadata structure, no matter how complex, can be mapped in it and you can set up elaborate workflows for the manual or automatic changing of metadata.

With cavok, we often transcend system boundaries in doing that: Automatically receiving metadata from other systems or transferring it to them, instead of the laborious and costly maintenance of metadata in several places, is highly recommended and possible with reasonable set-up effort.

Possible scenarios:

  • Using the article number as the image name, the ERP or PIM system is automatically queried for the name, size, weight, etc.

  • The CMS or shop system automatically retrieves photos from cavok in a size suitable for the presentation of the product.

  • When entering keywords for assets, a specialized dictionary is automatically queried that delivers and enters the translation of the terms in several languages.     

It is very easy to name files and folders, but unfortunately, only purely hierarchical connections can be depicted. Where in the above diagram would you file a photo of Albert Einstein? In a file with the name of his place of birth (Ulm, 1879)? Wasn’t he also a child of other cities, e.g. Munich (1880), Pavia (1895), Aarau (1896), Zurich (1896), Winterthur (1900), Bern (1902), Zurich (1909), Prague (1911), Zurich (1912), Berlin (1913) or Princeton (1932)? And isn’t his work valid for the entire universe?

And that is still not saying much about the image itself. A couple of other bits of information can be put in the file name, but unfortunately there are no real rules for the naming of folders and files at the operating system level. In our example, you could have written "apple pie" instead of "Europe" and it would make no difference to the operating system.

For everything else you need the search function or, as a crutch, "links" and "aliases", that is dummy files in folders that refer to files in other folders.

Any database can do it better, but neither Windows nor MacOS nor Linux "think" like a modern database, but still like the great-grandparents of the first MS-DOS PCs.

To solve this problem, DAM systems were developed and for solving most problems, cavok is an outstanding tool.

cavok Einstein EN
cavok Einstein Mobil