Orientation for cataloguers, field specialists, and DH researchers

What is in this site?

This resource provides basic instructions on using, troubleshooting, and expanding DigIn. If you're a cataloguer working with data that will be fed into the integrated data website, check out the contents of this Getting Started section, and then focus on Data Models and Data to Curate Relationships, which provide guides to handling the data headed into DigIn. Also check out the field-level mappings for specifics on how each term is mapped.

Overview - the nitty gritty

The O'Keeffe Museum Collections website is a data-driven application that makes its art, archival, and library collections, and the digital assets, accessible as a webpage and as a regularly updated open-licensed dataset. Everything in the site is driven by a data point catalogued and maintained by your collections specialists in the existing data management applications. The data formats are then aligned to a data model that allows it to be linked across its various entities so art objects, archival material and ephemera, and library cataloguing (alongside people, places, etc.) are all able to be represented in similar ways and easily connect with each other. Building the user-facing webpages of the site from the published linked data ensures not only that the data is usable in other projects, but also that data users can benefit immediately from updates to the museum's cataloguing, inincluding the model and the emergent links between things.

From 20,000 feet the process looks like this:

{ field specialist catalogs something } --> { enter into source system } --> { export to DigIn from source system } --> { make into linked data } --> { build webpages } --> { release site and pages and supporting data }

Cataloguing standards are tools, data standards organize them

Different fields have different needs in their cataloguing. While an archivist may need to synthesize biographical and historical details to provide framing cataloguing for a box of letters, an art registrar may need to note the intricate material construction of a work, and a librarian may need to specify a particular book as being from one of a swath of editions and reprints. Each of these fields has developed cataloguing tools that help clarify those specific challenges and make them expressible to other specialists and the broader public, whether analog or digital.

In order to be able to use cataloguing as data, the communities of archivsts, librarians, and art registrars have developed their own data standards that allow for expressing this cataloguing as data. This allows data to be circulated and used by those communities' publics: archival tools have EAD/XML downloads that provide machine-readable forms of their collections and finding aids; library catalogues make MARCXML downloads available that power citation managers and interlibrary loans; and while art cataloguing may not have the same community-wide data sharing standards, there are guidelines about how to express physical and contextual knowledge about an object (such as CDWA), as well as data standards for exposing that knowledge as data snippets for machines use.

Linked data builds on expressively catalogued and organized data

Where cataloguing and data standards build the capacities of a specific subfield of study, linked data enables integrating across those subfields. Where cataloguers focused on the legibility of a piece of data to their immediate users and community, linked data is typically one step removed in terms of abstraction. Where an archivst might synthesize a title for a letter that notes its correspondents, then an art registrar might look through those letters to find an authoritative title to enter it for a specific artwork, both the letter and the art object are being said to have a title.

So an archivists's EAD/XML snippet that declares a title:

<c id="component_1" level="item">
   <did>
    <unittitle>Letter from ABC to XYZ, 3 June, 1933</unittitle>
   </did> 
</c>

And a registrar's snippet declaring a title:

id,title
object_1,"Bear Lake, New Mexico"

Are both represented in the same structure as linked data:

{
    "@id": "http://example.com/archive/component_1",
    "identified_by": [
        {
            "type": "Name"
            "value": "Letter from ABC to XYZ, 3 June, 1933"
        }
    ]
}
{
    "@id": "http://example.com/art/object_1",
    "identified_by": [
        {
            "type": "Name"
            "value": "Bear Lake, New Mexico"
        }
    ]
}

References

  • TBD