NGA-15-RFI-0071TW.docx

DOCX document 60 KB Posted

Attached to
Electronic Digital Asset Management
Solicitation number
NGA15RFI0071
Issued by

About this file

NGA-15-RFI-0071 NGA-15-RFI-0071TW.docx

View the file

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

FedBizOpps Sources Sought Notice

CLASSIFICATION CODE

SUBJECT

CONTRACTING OFFICE'S

ZIP-CODE

SOLICITATION NUMBER

RESPONSE DATE (MM-DD-YYYY)

ARCHIVE

DAYS AFTER THE RESPONSE DATE

RECOVERY ACT FUNDS

SET-ASIDE

NAICS CODE

CONTRACTING OFFICE

ADDRESS

POINT OF CONTACT

(POC Information Automatically Filled from User Profile Unless Entered)

DESCRIPTION

See Attachment

AGENCY'S URL

URL DESCRIPTION

AGENCY CONTACT'S EMAIL

ADDRESS

EMAIL DESCRIPTION

ADDRESS

POSTAL CODE

COUNTRY

ADDITIONAL INFORMATION

GENERAL INFORMATION

PLACE OF PERFORMANCE

* = Required Field FedBizOpps Sources Sought Notice Rev. March 2010 Electronic Digital Asset Management 20785

NGA-15-RFI-0071

09-26-2015 N 541512 National Gallery of Art Office of Procurement and Contracts 2000B South Club Drive Landover MD 20785 Janet Wu National Gallery of Art Office of Procurement and Contracts 2000B South Club Drive Landover, MD 20785 National Gallery of Art 6th Street and Constitution Avenue NW Washington, DC 20565 20565

USA

jt-wu@nga.gov

Enterprise Digital Asset Management System

Synopsis

THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This RFI is issued solely for information and planning purposes; it does not constitute a Request for Proposal (RFP) or a promise to issue an RFP. Furthermore, those who respond to this RFI should not anticipate feedback with regards to its submission; other than acknowledgment of receipt - if a request for an acknowledgement is requested by the submitter. This RFI does not commit the Government to contract for any supply or service. The National Gallery of Art (NGA) is not seeking proposals at this time. Responders are advised that the NGA will not pay any costs incurred in response to this RFI. All costs associated with responding to this RFI will be solely at the interested party's expense. Not responding to this RFI does not preclude participation in any future RFP.

The information provided in this RFI is subject to change and is not binding on the NGA. All submissions becomes the property of the NGA, and will not be returned.

Summary

The mission of the NGA is to serve the United States of America in a national role by preserving, collecting, exhibiting, and fostering the understanding of works of art at the highest possible museum and scholarly standards. Central to this mission is the production, management, use, and dissemination of the Gallery’s digital assets, including digital still and moving images, audio, and documents related to the collection. The Gallery has been performing digital asset management, using several different solutions, for over a decade.

The NGA, seeks the services of an Enterprise Digital Asset Management System (eDAM).

1. Introduction

The Gallery is performing market research to establish the vision for its next generation enterprise Digital Asset Management system (eDAM), to understand the current technology that might contribute to such a venture, and to set an acquisition strategy including levels of resources and a timeline. This investigation has progressed to the point where responses from the vendor community to a set of focused questions would be valuable guidance.

1. Background

The mission of the National Gallery of Art (NGA) is to serve the United States of America in a national role by preserving, collecting, exhibiting, and fostering the understanding of works of art at the highest possible museum and scholarly standards. Central to this mission is the production, management, use, and dissemination of the Gallery’s digital assets, including digital still and moving images, audio, and documents related to the collection. The Gallery has been performing digital asset management, using several different solutions, for over a decade. The following sections describe the present states of these systems.

2.1 Division of Imaging and Visual Services

The Division of Imaging and Visual Services (DIVS) produces, manages, and distributes the primary digital images of objects in the Gallery's permanent collection, non-NGA objects included in special exhibitions, and images of Gallery events. DIVS provides images for the purpose of access from the Gallery's public website, intranet, collection management system (TMS), NGA Images and many other systems and services. Our collection management system is The Museum System (TMS.)

Since 2005, DIVS has used Extensis Portfolio Server to manage digital assets and associated metadata. At present, DIVS manages over 300,000 digital assets in multiple catalogues. Images are stored on the DIVS server in a hierarchical folder structure, and cataloged using the Portfolio desktop client. Portfolio is linked to a data extract of the Collections Management System (TMS) that is refreshed nightly.

2.2 Library Image Collections

The National Gallery of Art Library has two areas of digital media collections – digital images from the Library Image Collections, and a combination of digital images and PDFs from the Library’s rare books collection. Both are cataloged in our Voyager Integrated Library System (Mercury), with links to the digital files stored externally. We have configured the Voyager web interface with a JavaScript image viewer.

The Image Collections database contains 380,000 items cataloged in Voyager, of which approximately 85,000 unique digital images (jpegs) are referenced. Growth is approximately 10,000-15,000 per year. The digital media from the rare books portion of the Library are approximately 10,000 in number at this point, growing by about 2,000 each year.

2.3 Gallery Archives

The Gallery Archives is responsible for long-term care of the permanently valuable historical records of the National Gallery of Art. At present, holdings include some 5,000 cubic feet of analog files and other media (film, audio, video), 23,000 architectural drawings, and an estimate of well over 200,000 photographs.

A purpose-built relational database serves as the permanent repository for archival descriptive data and bibliographic metadata. Digital files are preserved in a server-based structured digital archival repository, which presently holds more than 150,000 digital objects (some 4 GB). Extensis Portfolio serves as the digital asset manager for image access and digital management tools. More than 122,000 archival images have been cataloged in Portfolio.

2.4 Departmental DAMs

In 2008 the Gallery created the Digital Asset Management program to facilitate more efficient use, storage and management of images and metadata by other Gallery departments. Participants receive a Portfolio digital asset catalog (DAC) and a location on the digital asset repository (DAR) to store images and media files. The digital asset catalog helps Gallery departments manage their own department-specific image collections and to identify images that are of long-term importance to the Gallery. Eight departments are actively participating in the eDAM program, and catalogues contain digital assets ranging from 1,000 to 10,000.

1. Goals, Objectives, and Approach

The Gallery’s vision for the eDAM is to develop a single comprehensive system to provide a structured framework for the storage, organization, and access of digital media of various types, including still images, video, audio and selected documents, for all Gallery departments. The Gallery understands that this project cannot be directed toward simply selecting and implementing a software or software-and-hardware solution. Rather, the more important focus must be on changing our business processes and assigning responsibilities. The scope of the change will include:

· Redesigning business processes

· Clarifying assignments of responsibility, including new responsibilities

· Selecting a capable platform to be used during a period of seven years

· Implementing a solution based on the selected platform

· Continually refining the solution and business processes

We intend to proceed in phases. Currently we are reviewing the market, holding internal discussions, agreeing on requirements, mapping out new business processes, and selecting a product or products as the platform for development of the solution. We intend to finish this phase early next year. Subsequently, we will implement the solution based on the selected technology, and initiate use by a few pilot groups. Finally, in the following years, we will expand and refine the system in a series of short cycles, each yielding tangible improvements or extensions.

1. Submission Instructions and Conditions

The Gallery welcomes responses that may assist us in better understanding digital asset management, in preparing our formal solicitation, and in identifying qualified partners in this initiative. After review of submitted materials, the Gallery may contact respondents to further discuss their submittals and or invite online or in-person demonstrations of their offerings.

Responses should be addressed via email covering topics described in sections 4, to

Ms. Janet Wu at jt-wu@nga.gov

Responses should be delivered no later than 3:00 PM Eastern Daylight Savings time on Sept 26, 2015.

Initial written responses should be no more than 25 pages (assuming Times new Roman, 12 point font double spaced, with one inch margin), as explained in detail below.

4.1 Cover Sheet

Please include a cover sheet identifying the organization responding and providing a point of contact, with email and telephone number, to whom questions or clarifications regarding the response should be directed. If this point of contact is not technical, the cover sheet should provide a separate technical point of contact.

4.2 Company Overview (maximum 2 pages)

The Gallery is looking for an organization with the technologies and skill to assist it in implementing an enterprise digital asset management capability and to support the expansion and improvement of that capability over a period of several years. Please provide an overview of your firm and its capabilities, including its core business, location, and size.

You should describe your firm’s background and organizational history, years in business, and range of services provided, as applicable to this RFI. Include information bearing on the viability of the company, for example, trends in annual revenue or number of employees. Please also indicate the number of staff, and their role currently engaged in development of digital asset management systems and processes.

Please indicate the locations of your offices, the number of staff members in each, that could contribute to a project of this nature.

Please identify your client base (current and over the past 3 years) for digital asset management work that is similar in scope and complexity to the Gallery’s project described section 2 and 3 of this document. The Gallery is specifically interested in any previous experience your organization has working with clients in the museum or cultural heritage industry (including galleries and archives).

In addition, please describe the detailed implementation methodology, installation, configuration, integration/customization capabilities of your company; that is, the size (if any) of your services branch, their capabilities and skillsets. If you don’t have these capabilities in your organization, please provide information about your partners who can provide these services and their location In this case, please also specify if you worked with these partners in the past and what type of projects you cooperated on.

4.3 Product/Platform capabilities

The attached spreadsheet (Attachment 1) lists our most important capability requirements – please answer these using 4 categories:

· Yes, the product provides this feature, out of the box (with a possible one time configuration)

· Yes, with customization (high, med, low), where High is defined as more than 50 hours, medium defined as between 20 and 50 hours, and low is defined as less than 20 hours of custom development/configuration

· No, but this feature is planned for a future release (when)

· No, (but optionally) an alternative out-of-the-box feature/3rd party tool could be used instead

Please describe any important clarification in the “Comments” column.

4.4 Core Questions and Requirements (maximum 5 pages total)

Please respond to the questions below in a short narrative.

1. What type of assets does your product support (still images, audio, video, Word document, PDF, etc.) and what types of transformations are possible? Please provide a list of supported file formats.

1. Can the DAM be integrated with other systems, such as our collections management system, (TMS)? Do you have experience integrating with TMS specifically? At a minimum, integration is defined as providing a bi-directional data crosswalk between the systems.

1. Do you have Application Programming Interfaces (APIs) and what are the capabilities of the API set? If programming libraries are provided for the APIs, what languages are supported?

1. Do you provide cloud-based hosting capabilities, or is it feasible to do so with your product? If so, what are the limitations? Are there hybrid (part cloud, part local) options? Is the product integrated with other cloud based services such as CDNs, virtualization services, authentication services?

1. What are the metadata capabilities and constraints of your system? Can custom sets of meta-data be applied to different collections of assets? Does the system support the use of metadata standards? If so, please list.

1. Is metadata extractable from images, audio, video, office documents, PDF files, and can those formats be transformed into alternative formats using your product?

1. Is your product stronger with some classes of assets than others? Are there any major classes of assets explicitly not supported or poorly supported?

1. What are your search capabilities/features? (Search across asset types, saved searches, refining searches, asset aware search, semantic searches, etc.)

1. What types of permissions can be assigned within the eDAM system? At the user, asset, or field level?

1. Does your firm have experience implementing eDAM systems for cultural heritage institutions?

4.5 Pricing

In the first phase of the project we would try to store 750,000 still images, 2,500 videos, 2,500 audios, and 10,000 misc. documents in your product. The approximate user base would be around 50 users.

Knowing these data points, please provide information about your license model (the names of the modules you sell separately, the general license mode: per user, per seat, per CPU, concurrent users, etc.) and your approximate license pricing. In addition, if you provide installation, configuration, and customization services, please provide hourly rate information for these.

In addition, please provide information about your typical installation/configuration approach, its timeframe in weeks and approximate total cost.

1. Product Demonstration

Based on information in written responses to this request, a small number of respondents will be invited to demonstrate aspects of their solutions. These demonstrations are intended to assist the Gallery in understanding the current state of the art of digital asset management, as it applies to our needs—focusing on the user / system interactions we envision.

If you are invited for a demonstration, we would like to see the following 5 scenarios demonstrated:

Scenario 1: Asset cataloging Please demonstrate how a user adds images to the system and assigns metadata specific to that asset category or group. Demonstrate the ways in which a user assigns metadata to individual and multiple assets, and assigns metadata from a pre-defined list or other controlled vocabulary and how the system validates metadata. Finally, please demonstrate how assets can be ingested in bulk and metadata applied separately.

Key Functions to Demonstrate

· Add images to DAM

· Assign metadata for a particular asset category – collection image, event image, event video, conservation image, audio recording, etc.

· Assign metadata from an external system

· Assign metadata using a pre-defined list

· Assign metadata to multiple assets in an asset group

· Assign metadata to individual assets

· Metadata cloning from parent file to derivatives

· Bulk ingest assets and metadata separately

Sample user stories for the scenario:

1. A photographer shot a drawing from the Gallery’s collection and needs to add the original capture to the DAM and record the appropriate metadata for each image. Relevant metadata includes photographer name, capture device, light quality, light spectrum, and view description. Since this is an image of a collection object, additional descriptive and structural metadata relevant to images of art objects is required. Some of this data needs to be automatically imported from the collections management system after the photographer records the object ID. For example the name of the artist who created the work, the title of art object, and its accession number. The photographer is also required to identify the view type (primary, alternate, etc.) and a sequence number within the view type.

After completing color corrections, the photographer needs to add derivative images to the system. The derivatives need to be linked to their parent asset and most of the metadata from the parent record needs to be assigned to the derivatives.

1. Another photographer has photographed a Gallery event and has 50 images to add to the DAM. S/he only needs to assign metadata that is relevant to the event, such as event title, type, location and notable persons that appear in the images. A large controlled vocabulary is used for selecting the notable persons. S/he is assisted by the system in selecting the appropriate persons from the large list of available options.

1. The Gallery Archives department receives a large group of digital scans of archival documents created by an outside vendor. The metadata is contained in a csv file. The digital images are ingested into the DAM in bulk, and metadata is imported from the csv file. Some of the metadata fields do not validate successfully or are incomplete. These assets are left in a pending state until they can be manually reviewed and corrected.

Scenario 2: Search, preview, and download/share

Please demonstrate the various ways a user could perform a search in the DAM, view metadata, browse images, download images with and without transformations (such as resizing). Demonstrate how a user would create a group of images, enter a custom name for the group, and share that group with another user or group of users.

Key Functions to Demonstrate

· Perform search by unique ID

· Perform search by keyword

· Browse assets and filter or narrow the results using faceted searches and multiple search criteria

· View and navigate metadata fields and metadata sets

· Apply metadata to a group of assets

· Create group of images

· Add a name to a group of images

· Share a group of images

· Download full resolution tiff and a jpg suitable for presentations

· Preview a video

Sample user stories for the scenario:

1. An imaging technician has received an assignment to make inkjet prints for 12 objects in the Gallery’s collection. S/he needs to search for the images in the DAM by a unique identifier, review the metadata to ensure s/he has found the correct images, and download the full resolution tiff images for all 12 to her computer.

1. A curator is giving a lecture and needs images of 40 objects that represent the Gallery’s collection of American paintings to include in his presentation. He does not have a specific list of objects and prefers to browse through the available images. Then, after selecting the 40 images, he needs to download them in a size and format suitable for Power Point.

1. A user has discovered a video by searching the DAM and wants to watch a preview before downloading it.

1. A curatorial assistant is gathering images for a web feature for a special exhibition. S/he searches the DAM to find the relevant images and creates an asset group. S/he names the asset group with the exhibition name. S/he then shares the group of images with the head curator for final review and approval.

Scenario 3: Access controls and versioning

Please demonstrate the types of access controls that can be applied to assets and metadata, and the various permission levels applicable to user roles, user groups, internal, external, and anonymous users. Demonstrate the act of demoting and restricting an asset.

Key Functions to Demonstrate

· Access control at the asset level

· Granular permission levels for user groups

· Change the accessibility of an asset or groups of assets and the associated metadata

Sample user stories for the scenario:

1. A conservator conducts technical imaging of a painting during the course of treatment. The technical images are added to the DAM, but users have varying levels of access or no access to the files. Users within the painting conservation department have full access to view and download the full resolution image, and permissions to view and edit the metadata. Other users within the Gallery are able to view the image and metadata, but can only download a smaller jpg and cannot edit the metadata. Still other users may only be able to view the asset in the DAM, but cannot download it.

1. In 2007, the imaging department scanned a color transparency of a painting in the collection. The scan exists in the DAM and is the current, preferred image for the object. In 2015, it is decided that new digital photography should be done to have a higher quality image. After photography, the new image is added to the DAM and replaces the scan as the current, preferred image. However, the scan must be retained in the DAM for historical purposes, though demoted and access restricted.

Scenario 4: APIs

Please demonstrate the types of queries and commands available through the eDAM’s application programming interface and comment on how much of the eDAM’s functionality is also available through APIs. Demonstrate how an external application (such as a website) can query the eDAM and receive back metadata and assets in an efficient manner without overloading the eDAM or the web application

Key Functions to Demonstrate

· Programmatic access to eDAM

· Application integration with other systems

· Automated event-based messaging or equivalent

· Complex metadata management and metadata querying

Sample user stories for the scenario:

1. An image in the DAM is marked for web publication. A process in the DAM detects this flag and proceeds to make derivatives (5 JPEG images and 1 PTIF image suitable for zooming). The DAM stores the derivatives along with derivative-specific meta-data and creates the associations between the source image and the derivatives. Once created, the DAM issues messages to a web application that new derivatives have been created. Using the DAM APIs, the web application finds metadata associated with the new derivatives images and clears its image cache. Later, in response to a web request, the web application uses eDAM APIs to identify one of these derivatives, download it, and cache it locally for performance and security reasons.

1. Gallery Archives maintains a database with detailed descriptive metadata. A Gallery Archives technician is preparing a new entry about the East Building renovation in the Archives Database. Via Archives web application, the technician queries the eDAM’s web services with a custom Javascript widget to identify and link relevant asset records to the Archives Database entry.

1. A curatorial assistant is using a web content management system to author scholarly texts about an art object. An integration between the web content management system and the eDAM allows the assistant to query the eDAM directly from within the Gallery's content management system for its public facing website. The assistant finds that no conservation images are available for this art object and, after locating them on the network, s/he logs into the eDAM and opens an asset group “OSCI-Dutch”. S/he then creates a new group of assets under it called “1937.1.73 – technical images” and uploads technical images of the art object into the asset group. S/he then assigns a metadata template “OSCI Technical Images” to the asset group and proceeds to enter relevant metadata such as the object ID for the asset group and metadata such as “wavelength” for each asset individually. In validating the metadata, the eDAM catches an error and reports that all technical images must be of the same resolution. S/he removes the image that doesn’t match and returns to the web CMS where s/he is able to locate the newly updated technical images.

Scenario 5: Reporting and quality control

Please demonstrate the reporting and notification capabilities of the eDAM system.

Key Functions to Demonstrate

· Customized reporting

· E-mail notification

· Monitoring health of the system

Sample user stories for the scenario:

1. The current specification for our standard high-resolution image delivery file is 4000 pixels on the long dimension. The eDAM manager needs a report of every delivery file in the eDAM system that is either larger or smaller than 4000 pixels on the long dimension.

1. Several times a year the eDAM manager creates a report that covers the percentage of the Gallery’s collection that has been digitized. The report is broken down by classification (painting, sculpture, photographs, drawings, etc.). He needs a report from the eDAM that counts the number of digital images of collection objects for each classification. The report counts only the current, preferred images (i.e. only one image per collection object).

1. The eDAM librarian would like to find out who entered a specific metadata field for an asset last month.

1. The head of conservation would like to receive a daily report via e-mail of any newly entered or updated conservation images and a thumbnail of the asset. The report should not be sent if there is nothing to report.

1. Someone loads an image that is 50,000 pixels x 60,000 pixels. In attempting to create derivative files, the system runs out of memory and must abort the operation. An SNMP trap and a log message with ERROR status is created. The automated process to create the images retries the operation periodically and the trap and log message are created until the source asset is deleted or until the system is shut down and the memory increased sufficiently to perform the operation.

Requirement description
Vendor Self-Assessment of Ability to Meet Requirements
Comments
Yes, out of the box (with a possible one time configuration)
Yes, with customization (high, med, low)
No, but this feature is planned for a future release (when)
No, (but optionally) an alternative out-of-the-box feature/3rd party tool could be used instead

User Interface

EXAMPLE: The system provides a web interface based only on open standards such as CSS3 and HTML5 that are supported by common web browsers on all major desktop operating systems.
no
high
yes, Q2 2016

The CSS has to be modified to use a response design - this is actually in the works and we plan to release in the Spring;

The system provides a web interface based only on open standards such as CSS3 and HTML5 that are supported by common web browsers on all major desktop operating systems.

The system supports Unicode for character data and uses a widely supported encoding scheme such as UTF-8 for data transmission and persistence. The system uses a Unicode ready font suitable for rendering texts in many languages.

Search and Organization

Simple search and advanced search modes are provided, e.g. multiple metadata searches can be combined to form a single complex search.

Search includes a faceted drill-down based using metadata from the asset or collection of assets.

Search results can be used to save a working set that can be shared with other DAM users (including the anonymous user) for collaborative purposes.

Free text searches can be tuned to prioritize metadata over indexed content contained in assets such as closed captions, PDF content, etc.

Assets can be arranged in multiple hiearchies making it efficient to locate and work with specific collections of assets.

Assets, Ingest, Export

The system assigns a unique ID to each asset.

Versioning of assets is fully supported.

Assets can be loaded into the system in bulk.

Images, Audio, and Video files are supported in a plethora of formats and a broad selection of transformation operations are provided. Certain document and archive formats such as PDF, ZIP, TAR, and MS Office formats are supported as well but not necessarily with robust indexing and transformation options.

The file name for an asset downloaded from the DAM can be automatically assembled according to a pre-defined combination of metadata fields to conform to naming conventions.

Asset previews in search results and other asset listings are sufficient to convey the content of the asset without having to open it or play it.

A collection of assets can be downloaded in a zip or equivalent container format.

Derivatives

The system can generate a wide range of derivatives for all supported asset types, both on demand, and automatically according to rules, e.g. image for a video, audio file from a video file.

There is a high degree of customization over all aspects of derivative generation including, e.g. for images, there is control over the resizing algorithm, derivative resolution and fit constraints, and color profile transformations.

Derivatives are tightly connected to the source asset but handled differently from source assets within the system.

Pyramidal TIFF files and JPEG 2000 formats are supported derivative formats.

Embedded Metadata in Assets and Derivatives

The system can identify embedded technical metadata such as color space, bit depth, ICC profile, pixel dimensions, and resolution of images; length, bit rate, and assistive technologies for videos, etc.

The system allows embedded metadata to be mapped to asset metadata fields when an asset is loaded into the system.

The system embeds metadata in derivative assets using a combination of metadata from the source asset and facts about the image itself, such as the width of the derivative in pixels which could be different from the source asset.

Metadata and Metadata Management

The metadata subsystem supports a wide range of metadata field types along with comprehensive and intuitive widgets for assisting users in assignment of descriptive, structural, and administrative metadata. Multi-valued fields are supported; the user interfaces for defining, presenting, navigating, editing, and validating metadata is intuitive.

A metadata field permitting the selection of multiple terms from a tree structure is supported, ideally with type-ahead assistance.

Sets of metadata fields can be defined and applied to assets manually or automatically according to rule sets.

Metadata templates, i.e. metadata sets with certain pre-populated values, can be saved and applied just like metadata sets.

Metadata can be assigned to assets in bulk using data from a variety of sources and a variety of mechanisms, e.g. data embedded within assets, provided in a file, rule sets, API calls, etc.

Metadata can be imported, exported, and updated via bulk operations without having to use the programming APIs.

Complex metadata validation rules are supported.

Metadata sets can be nested.

Assets and groups of assets can be related to each other with metadata and traversed bidirectionally

Permissions

The permission subsystem has permissions definable as deeply as a particular operation being performed on a particular metadata field for a specific asset. However, permissions also roll up quickly into permission sets, user roles, and groups.

The system provides a mechanism for applying rule-based permission sets to assets, collections of assets, metadata sets, and individual metadata fields.

Particular assets or metadata fields on assets are hidden from users without the appropriate permissions to read them.

Permissions, roles, and user groups are stored within the DAM system.

Security and Reporting

Anonymous access is configurable and enables searching and downloading assets with read permissions granted to the anonymous user.

The system supports multiple user authentication sources simultaneously and supports LDAP (including Active Directory), Kerberos, oAuth, and other popular authentication schemes in addition to having its own internal authentication mechanism.

The system logs all events, including asset uploads, downloads, scheduled routines, metadata updates, etc., in an audit log.

The system can be used to create and save ad-hoc reports based on data in the audit log.

The system provides a mechanism for sending e-mail alerts in response to events of interest.

The system has passed vulnerability testing using one or more security testing suites and security testing is built into the QA processes for the system.

User sessions expire after a configurable period of inactivity

Integration

The system provides an API and programming library implementations in Java and other popular languages, for performing any operation.

The system can be configured to send an automated message and payload to a different system via JMS or another messaging protocol in response to an event of interest.

The system can be configured to execute another DAM system action in response to a system event, e.g. regenerate a set of derivatives and distribute them to target systems when the original source image is updated or a new image matching certain criteria is loaded into the system.

The system's APIs support a robust querying mechanism for performing complex queries of the DAM data with result sets paginated to allow the volume of data returned to be controllable by the caller of the API.

System Monitoring and Operations

The system can be hosted on the Linux operating system and, if an RDBMS is required, supports multiple RDBMS systems, including open source DBs like PostGreSQL and MySQL in addition to commercial options like MS SQL Server or Oracle.

The system categorizes log messages using a logical severity level standard such as TRACE, DEBUG, INFO, WARN, ERROR, FATAL, etc.

The system can be configured to alert operational staff in the event that a message of sufficient severity is encountered, e.g. via e-mail, snmp trap, Java MBean, etc.

System capacity can be scaled up as the number of assets and demand for services grows. Scalability can be achieved by allocating additional memory or CPU cores or by installing the most performance sensitive parts of the system across multiple servers.

The system can be run effectively on virtualized infrastructure.

image1.bin

File details come from the government source that posted it. Updated .