Attachment_3.pdf

Attachment 3 – Technical Guidance for ConservationSpace Build

Attachment 3 Technical Guidance for ConservationSpace Build

Several technical challenges must be addressed in building Release 1.0 of the system.

This document presents some of these challenges, along with technical insights on each, as developed through investigations and discussions by the project team. This information is offered as technical guidance to the developers, to limit investment in unlikely options and focus attention on areas where it is most needed. While no part of this guidance should be considered mandatory, it does represent the current consensus of the project team as the point of departure for design and implementation.

Document Management / Case Management

Reviewing the need documented in the Enterprise Blueprint, it is clear that the core functionality of ConservationSpace has much in common with document management systems. There are requirements for collecting source documents and images, for workflow, for developing documents and reports as end products, for managing versions of those end products, and for collaboration with internal and external colleagues. In addition to these classic document management concerns, there are also requirements for creating and understanding parts or elements of a conservation document, fields or text fields, for creating, editing, and searching for them separately.

Although these features are often included in document management systems, they may also entail customizations. Building such features, whether from the ground up or as extensive customizations, could be time-consuming and expensive.

Implementation of case management for Conservation contains at least one particular challenge, in that two types of ‘cases’ may be recognized. On the one hand, each object or artifact that is a subject of conservation interest constitutes a case, much as each person has an individual medical history that should be tracked over time. Here, case management concerns would include chain of custody or evidentiary control (in the sense that the term is used in archives work). On the other hand, each project represents a different sort of case, whether it involves an investigation into only one object or many. Here, concerns would be more likely to include deadline, responsibility, and assigned resources. Nuxeo, at least, offers native case management capabilities, but this ‘two owner’ aspect of case management in ConservationSpace seems to provide particular challenges in implementation.

The project team identified two primary open-source document management offerings:

Nuxeo and Alfresco. Either of these would provide most of these common document management features, along with a solid platform on which to base further development. Both of these products have significant capabilities for configurability, internationalization, and user interface design. Nuxeo has been selected for use by several closely related projects. Given the realities of the initial budget and the significant unique features to be developed, the project must maximize its use of well-supported off-the-shelf products for standard functionality.

Digital Image Management

Images of the objects under consideration are essential to any modern conservation project. Most projects make use of several images for references; some projects may be responsible for producing, and reporting on many, many images, including images taken under differing lighting or different wavelengths. Conservators need a digital image management capability in which they organize and store their images for reference. In use, they will retrieve images from this store, often highlight or annotate them, and include them in their analyses and reports. Both Nuxeo and Alfresco come already integrated with digital asset management components.

Nevertheless, the management of images or digital assets in the system will be challenging. Conservators will wish to use images from many sources—their own work, repositories within their institutions, or sites across the Internet—and the system will need to make provision for this. Furthermore, some ‘digital assets’ may not be still images, but video, possibly audio, or other formats.

Conservators’ need for image treatment and manipulation is very great. Determining what capabilities are required and providing them to a sufficient extent will be another challenge. Annotation of images is an area where open source software (Annotation Ontology and Open Annotation Collaboration) is available and must be leveraged, as it is important for future adoption by the Conservation community.

Classification, Indexing, and Search

Like many systems built for expert practitioners, ConservationSpace must manage a great deal of information, providing ready access to source documents, technical references, images, previous work, and other materials, without interrupting the progress of the work at hand. Users will need to search or browse to find things quickly, and will want to tag or classify their information to aid themselves and others in finding it later. Several controlled vocabularies are current in the field of conservation; various users may choose to adopt one or more of them. Any approach to search or tagging must seamlessly manage synonyms by which concepts are known, mapping between vocabularies, and accommodate multiple languages, including full support through the system for the UTF-8 character set.

First Class Entities

First Class Entities describe system “objects” (in data terms) that have strong identities (ideally persistent URIs with referenceable URLs), carry metadata about their life history, and allow the attachment of both properties (attributes of the entity) and relationships (link relationships with other entities, typically with predicates that describe the type of relationship). We do not use the term “object” because it can be confused with an “art object” which is commonly used in the domain and in the system.

Creating the following first class entities has the added advantage of allowing the ConservationSpace data to be more easily shared with other institutions and art repositories, for conservation and other purposes.

For effective management and inter-linking of resources in the application, a number of "first class entities" are recommended:

• Project / Task

• Object (art, artifacts, etc.)

• Person

• User

• Artist

• Institution

• Annotation

• Relationships / links between entities (yes, even this could be a first class entity)

Strong Identity Management for Entities

The first class entities in ConservationSpace are expected to have a long life, providing primary reference supporting significantly important cultural artifacts. Data entities should be assigned unique, persistent URIs that are, wherever possible, exposed as persistent, referenceable URLs. Standards-based conventions for representing data (e.g.

PURL, DOI, Handle, etc.) should be used for this purpose.

Highly Related, Inter-linked Content

Establishing strong data relationships is particularly important given that the ConservationSpace data is likely to have a very long life – much longer than the potential life of a specific ConservationSpace application/system – and establishes provenance for the interpretation and valuation of major international works of art.

“Hiding” the knowledge of information relationships inside of unstructured documents that are not machine interpretable reduces the value of that carefully crafted knowledge.

Developers should consider how the application data can be modeled like semantic triples/n-ary relationships, so the data includes typed links (rather than just typical html-style links that carry no additional information). This is more than simply storing data in a standards-based format – it is ensuring that knowledge about the relationships between data entities is not lost because of modeling decisions underpinning the ConservationSpace application. It also allows simpler machine-readable data presentation on pages, using markup like RDFa and schema.org to present data on primarily human-readable pages.

Maintaining linking relationships serves long-term data integrity functions:

• Maintains better provenance of first class entities and their relationships

• Limits duplication of content and resulting loss of maintainability/single-sourcing

• Allows standards-based data sharing with other organizations long-term (e.g.

ResearchSpace, Linked Data)

Strong data relationship models also allow more flexible integration of vocabularies, thesauri, metadata across repositories/sites, which can increase the metadata available to conservators.

Annotations on Text and Images as Structured Content

Annotations are commonly used in conservation. In system data terms, they can provide additional value as "glue" between first class entities – annotations often describe something about a decision or action that relates the entity being annotated to another entity (for example, an annotation on an image may trigger a request for lab analysis, creating a relationship first to the request, and later to the resulting lab data).

To help the user tune the way the application responds to their work, annotations should have structure – they should be more than just a block of unstructured text. The specific requirements of that structure have not yet been fully defined, but it should be considered architecturally.

Unstructured Text as Source Material

Not all information will come to ConservationSpace fully analyzed and tagged with appropriate annotations. Much information, text and images, whether published or received from others, including non-Conservator correspondents, will consist only of free text. ConservationSpace will also need capabilities for searching, locating, and understanding these imported assets so that they may be efficiently incorporated into ongoing projects and the system repository.

Visual and Flexible User Interfaces

Conservation is a very visual occupation; the core activities are the close examination of objects, the development of reports on their condition, and the development of proposals for their preservation. All of these activities entail management of both large volumes of information and various types of images. In addition, conservation involves frequent expert judgment regarding the ordering of activities or the selection of source information. In discussions during the early phases of this project, conservation users often voice a concern that they cannot do their work using a green-screen, database type interface. They need to see images, often multiple images, to select from multiple documents, and they need the ability for flexible configuration of the interface to fit their individual circumstances and work style.

Nuxeo and Alfresco both offer options for frameworks on which to base development of a flexible, highly visual user interface. Selection of an appropriate UI framework is central to the design of the system, and will be an important element of the evaluation of the conceptual design to be prepared in Phase 2a. Nevertheless, the project team will be examining the choice carefully to assure that the selected framework assures:

• Good user experience o Rich page components o Cross-browser compatibility o Performance and speed o Support for mobile, tablet, and other small screens

• Good development efficiency o Scalability o Simplicity o Available open source extensions o Reduced need for custom code that cannot be contributed back to the community

• Solid business model o Broad acceptance and use o Large, active user community o Consistent product fix and release cycles o Vendor backing

Template-driven, Modular Page Design

A Conservator’s work is not “linear” – it requires interacting with a range of different physical and informational entities at the same time. Any system that supports this work must make sure that a wide range of resources (task info, people, media, notes/annotations, documents, external references, status, etc.) are available to the user in their tasks.

The design approach is data-driven – it is based on creating a small number of flexible template pages that are configured based on contexts, which include:

• Task(s) being performed

• Project status

• Object(s) being managed in the task

• Participant(s) in the task

• Organization/department configurations

• User preferences / configurations

Templates reduce the number of application pages, but increase their interactivity. To function flexibly, they need to be built up of modules that allow the user to have a dynamic set of related (and interoperable) functions available on the page. Use of modules is illustrated in the wireframes for Focus pages and in the Action Panels that are found on Workspace pages. The benefits that can be derived from the modular approach have been identified as:

• Greater flexibility for integrating information resources, because presenting multiple relevant modules on any page reduces the amount of seeking a user must do to locate and associate resources

• Increasing familiarity (reducing learning) because modules are reused, creating consistent interactions across different pages

• Potentially allows a greater degree of user configuration without undue code complexity

Offline Data Creation

Not all work is done in front of a computer, at a desk. Working on large art objects often requires going to work where the object is, rather than having the object brought to the conservator. Surveys can be performed outdoors or at another location (such as a country estate) where there is no network access. Collaborations between conservators and other staff often happen in meeting areas that are not as fully enabled as their offices.

So it is important to think about ConservationSpace architecturally as a set of components – some of which can be “uncoupled” from the host system for a period of time – that manage a range of data entities. Synchronization, status, and version management are critical for the user to interact effectively with the application and the interface.

Open Source

In order to assure that the initial costs for adoption are moderate and that the costs for maintenance and future adaptation also remain within bounds, ConservationSpace has adopted a strategy to use stable open-source and public domain technology insofar as possible, particularly for basic infrastructure. We expect ConservationSpace to run on an open-source operating system and to give preference to open-source packages or frameworks for the construction of workflow, data management, and search functionality.

Reliance on open-source technology poses significant challenges, including technical limitations of the available packages, legal limitations of the rights to those packages and any code developed on them, and practical limitations of the availability of support and of qualified developers. The project team will review open source product selections proposed by the developer to assure that they have beneficial licensing terms, an active user community, an advantageous business model, and that they are based on widely used, mature underlying technology.

Integration with External, Including Legacy, Systems

ConservationSpace will need to support interfaces with several types of external systems, but the most important of these are a collection management system (a catalog of objects in a collection) and a digital asset management system for managing images of works of art. Prominent examples of collection management systems are The Museum System (TMS), a commercial product from Gallery Systems, Inc., and CollectionSpace, a sister Mellon-funded project. Asynchronous exchange of data may be sufficient in some cases, but because of the prominence of workflow, close timing or ordering of events may also be necessary. The strategy for integration with external systems must be open and simple to implement. Ideally, this would use an open and modern mechanism, such as web services passing data encoded as XML.

Many of these external systems will be legacy proprietary or commercial systems, with limited availability of application programming interfaces. As of Release 1.5, and with increasing importance for later releases targeted to the broad community, interfaces to these legacy systems will be an important component associated with

ConservationSpace. Although the developer may be called upon to build only a minority of these interfaces, they will establish the pattern for plug-ins, connectors, or data transformations to be used to accomplish the integration. This pattern should be clearly articulated so that others can adopt it in constructing interfaces to other systems, and extensible.

Optional vs. Required System Integrations

Some integration with an institution’s existing systems and data – or perhaps with public APIs/systems – will be necessary (“required”) at the point at which they adopt ConservationSpace. At the same time, there may be some features within ConservationSpace that could benefit from integration, but it would be considered “optional” by the project, either because it is a roadmap item for a future release of ConservationSpace, or because particular institutions would choose not to do that integration as part of their configuration.

As a consideration for design and template management within ConservationSpace, there may need to be alternative templates/Action Panels for the scenarios where optional integrated data does, and does not, exist.

• If integrated data is not available, more capabilities will be required for the user to enter data that drives ConservationSpace screens and templates.

• If integrated data is available, there will be a need for increased messaging and status, as well as potentially more capabilities for looking up data from external systems.

Support for Common Cloud-Based Applications

There are a range of cloud-based tools and capabilities that have begun to be adopted by conservators and within the museum community generally. These tools provide efficiencies in their work. From the perspective of the ConservationSpace project such tools can off-load complex functionality to other cost-effective suppliers and open source capabilities.

Consider the role of open APIs as a part of the larger architectural planning, that allow users to do some of their work (particularly offline work) using common tools they may already use, such as:

• Data capture and storage with cloud sync: Evernote, Dropbox/Box, Google Drive, etc.

• Catalog and vocabulary sharing: WorldCat, Freebase, Dbpedia/Datapedia, Europeana, etc.

• Citation and reference capture and elaboration: Zotero, Mendeley, etc.

Configurability

Several areas of ConservationSpace require configuration to meet the needs of individual conservators or museums. These configurations could vary in the nuances of workflow—permissions required for treatment of a work of art, the controlled vocabularies to be enforced, or the specific contents expected in various types of reports or analyses. In some of these cases, local configuration could be expected to extend the types of data to be managed by the system, or change the appearance of the user interface. Finally, our business is an inherently international one, so the desired local configurations will include provisions for adopting the local language of the users.

Configuration

Multiple levels of configuration are envisioned for ConservationSpace to accommodate the different needs of the various users and institutions.

Generally, configuration should be flexible given the long-term goals of ConservationSpace, to be adopted by a range of institutions and individuals with a minimum of coding or customization required. The appropriate places for different types of configuration depend on the scope of the impact from change:

• Application-wide (admin)

• Institution, departments

• Individual users and ad hoc groups of users (for example, a specific project team)

Key functions for customization could include:

• Data entry forms – fields, order, layout

• Data entry required/optional settings

• Layouts of modules

• Workflows between tasks

• Permissions and roles

• Adoption of terminology sets, standard data reference lists, etc.

• Reporting on application/user activities (particularly for independent conservators who may need to report to contracting institutions)

• Character set appropriate for a local language, via UTF-8

Hosted and Multi-Tenant Systems

Although it is being developed initially with the participation of seven major institutions, the community of interest and intended user population is much broader.

Conservators work for cultural institutions of all sizes, for commercial enterprises, and in individual practice. The capabilities of ConservationSpace have the potential to serve the needs of all of these constituencies. It is important for the long-term viability of the product that all of them have access to it.

One potential challenge to this access is the degree to which information technology interest and expertise varies among the members of this community. While some users, particularly the larger institutions, may prefer and have the necessary expertise, to install and manage the system themselves, many others would welcome anything that reduced the IT barriers to adoption.

The first version of the system to be demonstrated by the project, being available only on the Internet, is a step toward reducing the IT barriers. It offers optimism for a ConservationSpace-as-a-service offering that might attract individual users sometime in the future. Hosting the system would be another way of reducing the IT burden on an adopter who wished a more customized functionality. There are many other formulas that could be considered, and that the project might try out as it matures through development and demonstration.

Hosted and Multi-Tenant Systems