We begin our detailed review of electronic resource management with workflow for electronic resources.  In order to understand the needs for functional requirements for any system to support electronic resource management, let alone construct a data model that hopes to support those functional requirements, it is necessary to understand the life-cycle of electronic resources and the workflow that is shaped by that lifecycle. In broad terms, the Workflow Flowchart deliverable begins with the contemplation of acquiring an electronic product, proceeds through product trials on to multiple reviews, through implementation processes, and then maintenance and review and finally ends when  a product has no further life in any incarnation. However, that simple description glosses over a wealth of details, complexities and frankly headaches.

I’m not going to try to cover all the pieces of the flowchart right now, because a great deal else to cover, but let me just draw your attention to how the four pages of the flowchart cover the lifecycle of an electronic product. On this first page of the flowchart, we are at the very beginning of the lifecycle of a product within a library.  The library is considering acquiring the resource, and the resource is in pre-selection stage.

On this second page of the flowchart, we are still in pre-selection stage, but we have moved into an intensive review period.  At the end of this stage, the library will have decided to acquire or not acquire a particular electronic product.

On this third page of the flowchart, we move through acquisition, receipt, product preparation for public release, and product preparation for future maintenance and control .  At the end of these stages, the product will be available to the library’s readers.

On this final page of the flowchart, we move through active life of the product, renewal cycles, and finally end-of-life and after-life stages of a product.  When a product no longer has a life in any form, then our work if finally considered done. And now that you understand better the complexities of electronic resources and the workflow needed to manage those complexities, it is time to turn our attention to functional requirements for a system to support that management.

The Data Structure provides the final rounding picture to a model whose description began with the Entity Relationship Diagram and the Data Element Dictionary.   This document is the ERMI-recommended approach to turning the conceptualization of the ERD and the DED into something approaching a relational database design. Each of the elements in the Dictionary have been mapped into entities described in the ERD.  Some new “elements” have been inserted to represent the needed relationships between entities that were described in the ERD as well. functionality (outline labels from the Functional Requirements document are included)

A number of the entities have quite long lists of elements that are mapped to them.  For convenience, we have created conceptual groups within entities where elements relating to similar issues are collated.  These groups have no function other than to make the data structure more humanly readable. This particular portion of the quite long Data Structure shows a group within the Administrative Information entity.  You will note there is a summary at the top of the outline, again to provide convenience for those using the data structure. The meat of the outline of each entity is the information associated with each element And with that, I will let the Data Structure speak for itself, and let us move on to XML.