 |
Metadata Engine (Database)
At the heart of Cumulus Core is Canto's
award-winning database engine. The primary advantage to offering
customers our own database engine is performance. Cumulus
Core's database engine was designed for metadata processing
applications, ensuring users can find what they need in moments,
not the minutes or hours other database systems can require
when querying massive metadata collections.
Fields
The following table describes the metadata field types
offered by Cumulus Core:
| Stores and plays back audio captured by
the client computer's audio system, or by a supported
digital camera that records voice. |
Series of "VCR" style buttons
|
Enables users to add
voice annotations to asset records using computer microphones.
Multiple Audio fields can be added to a catalog enabling
several users to record and store audio comments for others.
Audio fields can also be used to store and playback the
audio captured by audio-enabled digital cameras. |
| Stores a special binary field used for
asset references. The value is captured when the asset
is cataloged. |
File system path. The exact format depends
on the filing system on which the asset resides. Examples:
Windows: d:\Assets\image.tif
Mac OS X : Hard Drive:Assets:image.tif
Linux/Solaris: /Volume/Assets/image.tif |
Though not user-editable, asset reference
fields can be displayed for user reference. |
| Stores a binary data stream not suitable
for other field types. |
Not displayed |
Offers developers a universal data storage
object that can be used with custom applications that
either extend or interface with a Cumulus Core-based product.
|
| Stores boolean value: 0 or 1. |
Checkbox |
Provide users yes/no fields. Define field
label as needed: "Approved," "Archived,"
"Complete" etc. |
| Stores the size of an asset. |
A number whose format label is based on
the data size in the field: bytes, kilobytes, megabytes,
or gigabytes. |
This field is used to store the size of
the cataloged asset. It can also be used to store the
size of other assets too, if needed. |
| Stores a complete date/time pair. |
Complete date value, as defined by operating
system preferences. Example: 12/19/2006 8:32:21 PM |
Asset and asset record modification dates
are common uses for Date fields. They can be used for
any Date value that must include a calendar date and a
time value. |
| Stores only a date value. |
Date-only value, as defined by operating
system preferences. Example: 12/19/2006 |
Use any time a date value is required,
but a time value is not. |
| Stores a time value only. |
HH:MM:SS |
Use for any time value, such as the broadcast
time for a cataloged video program. Milliseconds can be
added after a trailing period. (HH:MM:SS.XXX) |
| Stores whole numbers with up to 32-bit
precision. |
Number |
Popular uses include the horizontal or
vertical number of pixels in an image. (See also, Long.)
|
| Stores colored codes users assign to asset
records. |
Label fields can either be displayed as
a horizontal stripe through the asset record, or they
can paint the background color of the asset record. |
Labels are typically used as a means of
rating or categorizing assets. Multiple label fields can
be added to a catalog, making it possible to provide each
user in a work group his or her own. |
| Stores a length measurement. |
The format (inches, centimeters, points,
etc.) is determined in the current user's preferences.
|
The horizontal and vertical dimensions
of an image asset are common uses of this field type.
|
| Stores whole numbers with up to 64-bit
precision. |
Number |
Use for any number when 64-bit precision
is required . (See also, Integer.) |
| Stores bitmap image data that's pasted
into the asset record, or gathered or created during cataloging
as a thumbnail. |
Asset thumbnail or user-pasted image. The
size of the image displayed set as "small,"
medium" or "large." The size of these presets
are determined in the active user's preference settings.
|
The most common use for a Picture metadata
field is to store a thumbnail image for the asset. But
the field can also be used to store other bitmaps that
are pasted into the asset record from the client computer's
clipboard. Examples include a scanned release form signed
by an actor in a video clip, or an alternate thumbnail
used to identify the asset. |
| Stores a number of star icons for user
labeling purposes. |
0 through 5 stars |
Enables users to set "star" ratings
to assets. Multiple rating fields can be added to a catalog,
making it possible to provide each user in a work group
his or her own. |
| Stores decimal numbers with up to 64-bit
precision. |
Number |
Asset license value or acquisition costs
are uses for Real fields, but the field can be used for
any purpose and labeled to reflect the data contained.
|
| Stores the dots-per-inch resolution defined
in a bitmapped file. |
Number |
Some image editing programs enable users
to define a dots-per-inch file resolution for certain
file formats. This field format can be used to capture
and store that information. |
| Stores textual information. |
Alphanumeric text |
String fields are the most common field
type, enabling users to store any textual metadata. |
| Stores an array of predefined String values.
|
Drop-down menu, a series of radio buttons,
or a series of checkboxes if set to enable multiple value
selections. |
String List fields enable administrators
to offer menus and radio button sets to users. Multiple-selection
string list fields enable administrators to define metadata
fields such as "Intended Audience," for which
there might be several appropriate values, such as "Children,"
"Teenagers" and "Adults." |
Fields can be added and customized
at any time, even after catalogs have gone live. If fields are
no longer needed, they can be deleted to reduce catalog size.
 |
Cumulus Core groups fields
required for certain file types to make it easy to add
all the fields you'll need based on the file formats you
plan to use.
|
Administrators can select fields for indexing, and even choose
which fields are considered by the QuickSearch tool, which enables
users to type in terms like they would using an Internet search
engine. Cumulus Core also enables applications to restrict the
editing of any given field to a certain user or group. Likewise,
fields can be hidden from users or groups that should not see
them.
All fields included in
a catalog are listed for easy reference. You can quickly choose
which fields are indexed for searching/sorting and accessible
to users from this list.
Categories
Categories in Cumulus Core are like
virtual asset containers. Each category can be assigned to
an unlimited number of assets, and each asset can be assigned
to an unlimited number of categories. Categories can be nested
to create hierarchies, and they can also be related. A related
category is a "pointer" to another; a single data
structure is accessed using multiple category icons. Categories
go far beyond the value offered by simple keywords in that
they can have their own set of metadata fields. This enables
work groups to establish categories as project asset containers
complete with project manager information, due dates, budget
data and more.
The Cumulus category structure
has been unique to Cumulus product line almost from the start.
Categories can be created, deleted, renamed or nested at any
time, permissions permitting. A special type of category,
called a "related" category, is one that is "physically"
connected to another. Example: Say you have a "BMW"
category under your "Luxury Cars" category list
that you also want under your "European Cars" category
list. Rather than having to make and manage two different
categories of the same name, Cumulus enables you to create
a second (or 3rd or 4th etc.) instance of the BMW category
and place it anywhere you like. A double click on any category
(or selection of categories) finds all assigned files.
Catalog Scope & Metadata Field Linking
Cumulus Core catalogs point to the
assets they contain—they do not contain the assets themselves.
The assets themselves can be stored in any location the engine
can access, on any medium supported. A single catalog can
point to assets stored on the server's locally mounted volumes,
networked volumes, Internet-based ftp locations, and even
removable volumes, such as optical drives. It doesn't matter
which operating system is used to catalog the assets; Cumulus
Core takes care of the path conversions needed for others
to access what they need.
Asset metadata are typically stored
within the catalog, but they can also be stored inside the
assets themselves, depending on the scope of the file format's
metadata support. Catalog administrators determine if metadata
are also stored inside assets. (Cumulus Core supports far
more metadata types than do the various metadata-supporting
asset formats. For this reason, asset metadata storage is
an option and not a restriction.) IPTC and XMP metadata standards
are fully supported and, for asset portability's sake, catalogs
can be configured to not exceed the limitations of these standards.
Field Linking enables administrators to "route"
incoming metadata into specific catalog fields. The example
here shows how the QuickTime and WMV "Author" metadata
fields will be copied in the Cumulus catalog's "Videographer"
field. Other assignments are shown too.
Cumulus Core makes it easy to route
incoming metadata into catalog fields you choose, thanks to
a feature called Field Linking. While the default field links
are sufficient for most purposes ("caption" metadata
goes into the Caption field, "notes" metadata goes
into the Notes field, etc.), you can assign as many custom
routings as you need. Field Linking also determines how and
when metadata should be written back to the assets.
 |
Field Linking
acts like a metadata triage of sorts, by routing the incoming
metadata into the catalog fields you choose. In addition,
Field Linking enables you to determine how metadata is
written back to asset formats that support it. |
Formula-based Field Values
Formulas you define can be used to fill an asset record or category metadata field value. Perform numeric calculations, concatenations of other field values, if-then decisions, and much more. Example uses include determining an image’s orientation (square, portrait or landscape), creating space-efficient output displays for views and reports, totaling license values, and more. The built-in formula editor features an in-line help reference to make formula creation easy.
Mirroring
Cumulus Core databases can easily be
mirrored to other systems in real time. Supported systems
include MySQL, MS SQL 2000/2005, Oracle and even another Cumulus
Server, which makes catalog backup easy and Web Access Client
load balancing possible. Even while mirroring, the Cumulus
Core database remains online and searchable, which means users
can rely on it to perform the search types it does so much
better than other systems, while they can also search the
external systems directly.
Catalog Journaling
Journaling helps ensure your catalogs survive system failures that could otherwise require significant downtime for catalog reconstruction. Journaling is available with all Cumulus Server editions, regardless of platform. A single check box turns on journaling, even for catalogs created in older versions of Cumulus.
Multiprocessor/Multithreading Support
All Cumulus Core databases are multiprocessor
aware and multithreaded for maximum performance. Application
developers can limit the number of threads available in a
Cumulus Core-based application, but the technology itself
can support an unlimited number.
User Preference Central Storage
User preference settings are always
stored on the server, enabling users to log in from different
desktops (or operating systems) and see their personalized
interface. Shared user-created resources, such as search queries,
are also stored on the server.
Server Customizations
The Cumulus
Core APIs support Java-based applications that extend
the functionality of Cumulus Core servers.
|
|
