CCO - Incorporating CCO in Your Workflow
Video Transcript

If you're looking for ways to make it easier to incorporate the guidance from
cataloging cultural objects into your cataloging workflow, you've come to the right
place.

In this video we're going to look at some different ways that you can streamline your
workflow, both for data creation and for ways that you might use your data in the
future.

Here's a list of some approaches that were going to go over in this video. I'll be
sharing some real world examples from my costume core project, which interprets
CCO in an application profile specifically for historic clothing, and has been
implemented in several different collections and cataloging systems.

CCO does put a lot of emphasis on using controlled vocabularies, as mentioned in
principles four and five of cco's 10 key principles. The Getty vocabularies and other
relevant authority listsare very important but it can be daunting to find the right
terms buried in those lists to help with that, you may want to invest some time up
front to create your own micro thesauri, shorter lists of terms use most commonly
for specific elements in the context of specific collections.

For example both the Getty art and architecture thesaurus and the Europeana
fashion thesaurus have many of the terms that are needed for describing historic
clothing. I have worked on a project called Costume Core for which I have
developed several different micro thesauri to make it easier for catalogers to
choose from a series of shorter lists for very specific features important to
describing clothing. 

Then these kinds of lists can be implemented as drop-down lists in a variety of
different tools. For costume core I've been able to implement this using data
validation in Google sheets, the simple vocab plug-in for Omeka, and the list
feature in JSTOR forum.

This also relates to the importance of index fields according to CCO as a part of
principal number seven. These kinds of drop-down lists can help with consistency, but
it's also important to allow for each different term to be entered individually, as
you're seeing on the left in an example from Omeka. Otherwise, indexing, facets, and
filters won't work properly.

How you catalog an item will affect not only how it is displayed to users but also how
they are able to find that item, and these can potentially interfere with each other.
The reference list plugin for Omeka lets you browse by subject, so for example you
can see a list of the full index of inputs entered for medium. If these are not entered
individually this list quickly gets crowded with entries that are not helpful for
browsing, such as the comma separated cotton, lace, metal that you see in the list on
the right.

It may be more user friendly to display a list of materials in a single line separated by
commas, but it's best if you can take advantage of features in different systems to
enter these separately but then have the system combine them together into a
display field. if that's not possible, the next best thing is to re-enter the data in a
separate step in a separate display field.

If you're working with a system that does not allow you to enter multiple entries for
an element, another approach is to be consistent with your use of separators
between different terms within that single entry. When you consistently use the same
character, like the pipe character you're seeing here or a semicolon or even a comma,
these can be recognized as individual terms in some systems or can easily be parsed
into separate terms later on.

That brings us around to another recommendation: to use functions or formulas or
other related features wherever possible to save you some time. If your database
doesn't let you create these different kinds of automations, you can do it in a
spreadsheet like Excel or Google sheets. For example you can use functions to split a
single column into multiple columns when you use a consistent separator like we saw
in the last slide, you can use find and replace to fix repeated errors, you can rearrange
columns and add new header names to map to a different standard or you can
combine fields into a single field to create display data.

Here's a more extreme example of that with a formula to concatenate several
different individual measurement number fields into a single display field, adding the
unit s and other phrasing and punctuation to make it a more user friendly display.
what you're seeing here has a two-step process where the autofill column has the
text created automatically, but then you can manually copy that into the display
column where you can make manual adjustments to make the phrasing better as
needed.

If you're working with a system that doesn't let you do these kinds of formulas, you
may want to do your initial data entry in a spreadsheet like this and then import it
into your system.

Here's another example of how the same kind of concatenation can be done as a
calculated field in a file maker database.

More advanced options for automated transformation of your data are possible using
XSLT to manipulate XML encoded data, or PHP with data in a relational database.
another tool you may want to use in tandem with your main system is open refine.
This is a free open source tool which can help you to filter, clean, transform, augment,
reconcile, and match data working within a spreadsheet format, converting from XML
if needed.

Here it's important to recognize that CCO recommends the use of a relational
database, The rich relationships and hierarchies that can more easily be expressed in
XML encoding or in a relational database structure are sometimes described as being
dumbed down when they are flattened out into a simple spreadsheet
However, there are times when a spreadsheet is appropriate: you may not have
resources for a fancier database and Google sheets or Excel are more accessible. You
may be working with legacy data that is in a non-relational format, or you may need
to exchange your relational data with another system that is not. Also as we've just
seen the previous slides a spreadsheet can sometimes provide power tools through
formulas and functions that your main system may not provide.

Many systems have tooltip features you can use to help remind catalogers about
CCO guidelines, like the consistency aimed for in principle #9. For example, in
Omeka I've entered specific instructions that are displayed in the cataloging page
to help remind student catalogers how to format their entries. This can also be
implemented in Google Sheets using Notes which appear as tooltips when you
hover over a column header. JSTOR Forum also has this kind of feature, available
when you click in the little "I" icon next to an element name.

Even when different systems implement CCO in slightly different ways, as long as
this use is well documented locally, it can be easily mapped and converted to be
interoperable with other systems, as expressed in principle #3. For example,
Omeka is largely built on the foundation of Dublin Core elements. Wherever these
map directly to relevant VRA Core fields, the Dublin Core fields are used but can be
easily mapped to VRA Core when exported. For VRA Core and even more specific
Costume Core elements that do not map easily to Dublin Core fields, the Classic
version of Omeka allows you to add your own custom fields which it calls Item
Type Metadata. The newer version of Omeka, Omeka S, allows you to import
ontologies in addition to Dublin Core, so I have been able to import both VRA Core
and Costume Core elements when using Omeka S.

Documentation of any non-standard metadata is key to interoperability.
For example, with Costume Core I have taken CCO's principle #10 a little further, to
prefer American terms over British terms within English language options. In some
cases, this is in conflict with the preferred term from the AAT or EFT, so this local
difference in preferred vs. variant term is documented locally, including authority
URIs. This way terms can be matched to the original preferred terms if they will be
exported to other systems.