Watchers and profiles: unlocking content for every possible use and audience via configurable utilities

Andrea Bour, The Cleveland Museum of Art, USA, Niki Krause, Cleveland Museum of Art, USA

Abstract

Collection managers, digital strategists, and interactive designers have pushed museum content creators to produce standardized, turn-key content for exhibitions and other collection-related projects, be they internal inventories, collections online, or digital interactives. We shoehorn curatorial content into CDWA, CCO, VRA, and Dublin core structures to produce organized checklists, orderly timelines, unified catalogues, and countless other digital interactions intended to inform and inspire our visitors. What have we learned? That museum scholarship is ever increasing and constantly shifting. Digital catalogues must be as agile and responsive as our researchers’ minds.

Keywords: cms, interactives, standards, content, collaboration, scholarship

The Cleveland Museum of Art dynamically publishes its entire collection catalog and interactives to our Collections Online and ArtLens app via weekly updates. In December 2015, CMA rolled out a new bespoke Collections Catalog and Management System (CCMS); the Athena CCMS was required to seamlessly integrate with these pre-existing public-facing interfaces on day one. Migrating from an 18-year-old bespoke collections management database to a standards- and schema-compliant catalogue without having to reinvent the existing data flow to these public facing catalogues forced the IT applications team and its vendor partners to think holistically about how to design the backend to flexibly support the rapid edit and publish cycle our interactives require.

Figure 1: Church’s Twilight in the Wilderness published simultaneously in Artlens (ipad), Collections Online, Collections Wall, Artlens (smartphone)

The existing data flow matched artwork metadata with images uploaded weekly to our Piction DAM:

Figure 2: data flow to Gallery One

 

 

 

 

 

 

 

 

 

 

 

 

The previous collections management database was a typical object-relational model, with “objects” (Artworks, Exhibitions, Constituents) directly represented by a table or set of tables, whose columns map to each of the object’s properties. This model, though efficient for storage and retrieval, was expensive to expand or change. Additionally, metadata audit was minimal, and the ability to assign conditional permissions non-existent.

The new Athena CCMS had the following requirements:

  • comply with the CDWA schema, yet be flexible and expandable, to meet needs not even anticipated for future storage and publishing; store and publish in the future;
  • allow many simultaneous content contributors and editors, while maintaining data integrity;
  • support role-based access.

It also needed to do the following:

  • provide a clear, detailed audit history of changes;
  • allow for dynamic expansion of roles;
  • restrict automatic publishing of new content prior to peer review.

Out of these requirements, the concept of “Watchers” was developed. Watchers are user-designed notifications of changes to the underlying data, including attribute changes, checklist changes, document uploads, etc. A Watcher can be defined to include a multi-step approval chain for any of these changes. Further, a Watcher can be a constructed to include both an approval chain and notifications.

Why DO users need to “Watch”?

Initial data entry for the CMA collections catalogue came from legacy registration cards and published catalogues. Some of the records had not been reviewed by curatorial or interpretation staff since the artwork first entered the building in 1916. The push to create at the very least a digital inventory record for every artwork in the building was necessitated by the plan to move the collection multiple times to accommodate the renovation and expansion project from 2003-2013. The pending renovation and expansion also prompted the museum to immediately begin a comprehensive image digitization project. These two efforts created a very collections management-centric catalog, focused primarily on inventory control, photography scheduling and art movement, and conservation task management; editing and publishing interpretive content were an afterthought at best. Due to the lack of audit and control over permissions, content was almost solely entered and edited by registration staff in order to keep the records “clean” for both internal workflows and the Collections Online catalog.

With the advent of Athena, curators could update scholarship ad hoc for the museum’s public-facing catalogs, not dependent on specific installations or exhibitions with rigorous editing processes to produce and publish content. Additionally, we could greatly expand the number of content contributors to include our education and interpretation (ArtLens content), library (Citations), conservation (publicly available condition statements) and exhibitions staff (checklist synchronization, loan approvals).

As we expanded the protocols for data entry, two major requirements arose:

  • User-group discussions revealed content dependencies. With so many contributors, the catalog has the potential to change very quickly; users—from docents giving tours to librarians fielding patron inquiries to curators collaborating on project checklists—required instant notification of artwork moving off-view; title, date and attribution changes; label (didactic) changes; exhibition titles and parameter refinements; updates on new accessioned and deaccessions are among the top changes of interest.
  • Key stakeholders in the publication process demanded oversight on changes for artworks or attributes in their purview. Because any user might suggest a title change, that title change needed to be reviewed before dynamically pushing out to the public in the weekly dataflow.

Designing a framework that could accommodate Watching

From a project standpoint, the Athena development team did not want to try to anticipate and “hard-code” every notification or approval into the system, especially as existing business practices were being reviewed and tailored to meet the museum’s long-range plane directives to “work smarter” and “maximize resources.” The upkeep on custom coding for notifications and approvals would have been a massive drain on the maintenance budget and a hindrance to expansion. Ultimately, the database was designed with these use cases in mind.

Athena’s underlying database is a web of Entities, Attributes, Classes, and Users derived from an attribute-value system. This framework, though less efficient in terms of storage than a typical object-relational model, allows the museum to define any number of “objects” (Entities: Artworks, Exhibitions, Projects, Constituents) each with its own set of attributes, all stored on the same set of tables for simpler retrieval and update logic when communicating with the Web application. New objects or additional properties for objects (for example, new attributes for artworks) can be implemented quickly with no impact on the underlying logic. But the most significant benefit is that this framework supports change-approval logic, no matter how many new objects or attributes are added to the system over time.

Setting up a Watcher

Working within the application, users can self-select notification of changes based on their own responsibilities or research projects. The entities and attributes are named and ordered as they appear in the Web application and reporting database, making it easy for a user to set up the notification without technical support. The simplest scenario is a curatorial assistant requesting notification for any changes to specific artwork attributes in their department’s purview.

Figure 3: user interface for setting up a Watcher

 

 

 

 

 

 

 

 

 

 

 

 

When an applicable change is made, the user receives a dashboard notification which provides a summary statement of the change and a link to the record.

Figure 4: dashboard notification

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Once the entity is opened, the user can navigate to the entity history to review the exact content change.

The key to setting up useful notifications is understanding the data schema and the business rules surrounding “states” for various Entities and related Attributes.

Figure 5: example of a state-dependent Watcher for a non-Artwork Entity

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Looking forward, we plan to expand the logic to allow users to request notifications changes based on an entity’s relationship to another entity or task. For example, title changes for approved artwork on a specific exhibition checklist.

Setting up a Watcher with an Approval Chain and the role of the Data Governance Committee

The need for certain stakeholders to approve specific attribute changes is also accommodated by the Watcher framework. As the specifications for approvals grew, it became obvious that an extension of the original project steering committee was required in perpetuity after go live. The Steering and Data Governance Committee is comprised of departments heads (or their representatives) in curatorial, exhibitions, collections management, conservation, and education, led by the CIO; the IT applications team provides support. In this forum issues concerning departmental responsibilities and data governance are discussed, debated, and compromised on, providing singular guidance to users regarding their roles and responsibilities, as well as approving specific cataloging guidelines proposed by the cataloging sub-committee. The Steering and Data Governance Committee formalized a set of business rules for go live which were implemented in the form of Watchers specifying approval chains as well as notifications. The primary example among these is the basic tombstone edit—Title, Creation, Materials, Credit Line—must be approved by the curator, chief curator, and the director of collections management before publishing in the weekly metadata flow to the public facing interfaces. This chain ensures all necessary stakeholders are informed of significant changes and provides quick editorial review for ad hoc editing.

Figure 6

Figure 7: approver dashboard

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Other examples of approval chains include updates to any type of artwork didactic and changes to legal contract status (accessioning, accession numbers). In short, many attribute changes which once would have required a complicated and inflexible permissions structure can be handled through the simple creation of an attribute-change approval chain. Pending approvals are stored in the database in a table of “Deltas” and are visible to users in any chain via a link from the entity’s landing page.

Figure 8: database query of pending approvals
Figure 9: user view of pending approvals for an artwork

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Once the terminal approval is reached, the proposed change is inserted from Deltas into the entity attribute, and the previous value is inserted into the entity attribute history, as are changes to attributes not requiring approvals.

Figure 10: entity history

 

Administration of approval chains and pending deltas

To ensure compliance with Governance decisions, only “Database Admin” users can define Watchers containing approvals. The Admin group must be aware of business rules surrounding an entity’s state, as well as possible logical conflicts of having two distinct approval chains for the same change. Thinking out the logic for the rules is similar to traditional permissions management, but there is no development required when a new rule is defined, or an old rule relaxed—a benefit that saves both time and money. The Watcher can simply be tweaked or deleted as approval requirements are agreed upon and authorized.

The use case of a user being unavailable to review a priority change for an extended period of time emerged early on after implementation. The ability to swap users in an approval chain when there are pending Deltas for that chain was a vital flexibility: staff went on vacation, or changed positions, or moved on, but the approval authority remained. For these scenarios, the Admin has a command line utility to swap in another user account, thereby keeping the approval chain active and allow the change to move forward without resubmission.

Figure 11: series of command line swaps and resets

 

 

 

 

 

Summary of benefits

Besides the technical benefits of logical flexibility and low cost change management of this framework, there have been several unanticipated user-base benefits. As we continue to push forward with expanding the depth of our content in Collections Online and ArtLens, one of the goals of Athena was to provide a wide-open database, promoting content creation from any users with content to contribute while continuing to protect the integrity of the records with oversight. The museum found that, after a year of use and curatorial changes, the Athena user base is more fully engaged in the cataloging process than they were previously. Users accustomed to the laborious and focused editing process traditionally associated with catalog and exhibition production did not previously understand the requirements for standards across collections, materials, and cultures. The use of access-controlled directories on shared network storage and Excel checklists for small projects has been reduced, and versioning issues associated with limited access documents eliminated. As users submit changes and receive feedback, they are coming forward with questions for the Steering and Data Governance Committee. In response to this growth of interest in a unified catalogue, the chief curator’s office initiated a cataloging subcommittee to research and review user inquiries regarding cataloging rules and possible expansions of the catalog attributes.

Profiles: breaking the mold of the unified catalog for specific contexts

After making great strides in empowering content creators and cooperatively defining cataloging rules and responsibilities regarding publishing workflow, CMA encountered a new use case: some projects required “special cases” of our standardized, computed attributes. For example, the standard tombstone caption for Collections Online appears in this format:

Series Title: Primary title, Primary Date. Creator Description or Creation Summary. Materials; Measurements. Credit Line.  Accession Number. Copyright.

Decontextualized from an installation, exhibition or catalog, this is the preferred description of a work of art. This description is helpful in its entirety in most general contexts in the database and exported documents as well.

Figure 12: truncated metadata visible in the Art and Stories of Mughal India app

 

 

 

 

 

 

 

 

 

 

 

 

 

 

However, as soon as that record is placed on a monographic exhibition checklist, the creator description and perhaps even the copyright text is redundant. In those cases, other attributes might need to be substituted to create a context-specific tombstone caption–perhaps a catalog raisonne number, or additional date types, or creation place. In the context of a conservation project, additional details about the facture, or materials and/or techniques not included in the materials statement might be required. In cases when a checklist is directly loading into a standalone app, a significantly shortened version of the title might be used.

Following the model of Watchers, Profiles provide a user-configurable system for defining attribute substitutions to apply within values which are themselves a computed combination of multiple attributes (as described above). Users can select the attributes and attribute qualifiers to compute and display within the context of their project. The profile, once defined and saved, can be applied to entities across the system and used in downstream projects. Profiles can be assigned an expiry date, after which any entities associated with the Profiles will roll back to the standard display values.

Benefits and drawbacks

The primary benefit of Profiles is to allow for temporary, project-specific publication of vetted and synchronized metadata. It also allows for multiple styles to exist at once. Once the profile is configured, the database can display and export any record in accordance with the Profile specifications on call.

The question for follow up is once we produce and publish variant captions, do we find our patrons confused finding the same artwork identified with different attributes in various interfaces?


Cite as:
. "Watchers and profiles: unlocking content for every possible use and audience via configurable utilities." MW17: MW 2017. Published February 9, 2017. Consulted .
https://mw17.mwconf.org/paper/watchers-and-profiles-unlocking-content-for-every-possible-use-and-audience-via-configurable-utilities/


Leave a Reply