Digital Asset Management System Pilot: Lessons Learned

Enterprise digital asset management (DAM) systems are beginning to be explored in higher education, but little information about their implementation issues is available. This article describes the University of Michigan’s investigation of managing and retrieving rich media assets in an enterprise DAM system. It includes the background of the pilot project and descriptions of its infrastructure and metadata schema. Two case studies are summarized—one in healthcare education, and one in teacher education and research. Experiences with five significant issues are summarized: privacy, intellectual ownership, digital rights management, uncataloged materials backlog, and user interface and integration with other systems.


U
niversities are producers and repositories of large amounts of intellectual assets.These assets are of various forms: in addition to text materials, such as journal papers, there are theses, performances from per forming arts departments, recordings of native speakers of indigenous languages, or videos demonstrating surgical procedures, to name a few. 1 Such multimedia materials have not, in general, been available outside the originat ing academic department or unit, let alone systematically cataloged or indexed.Valuable assets are "lost" by being locked away in individual drawers or hard disks. 2 Managing and retrieving multimedia assets are not problems confined to academia.Media companies such as broadcast news agencies and movie studios also have faced this problem, leading to their adoption of digital asset management (DAM) systems.In brief, DAM systems are not only repositories of digitalrich media content and the associated metadata, but also provide management functionalities similar to database manage ment systems, including access control. 3A DAM system can "ingest digital assets, store and index assets for easy searching, retrieve assets for use in many environments, and manage the rights associated with those assets." 4 summer 2000, the University of Michigan (UM) TV station, UMTV, was searching for a video archive solution.That fall, a UM team visited CNN and experienced a "Eureka!" moment.As James Hilton, thenassociate provost for academic, information, and instructional technology affairs, later wrote, "building a digital asset management into the infrastructure . . .will be the digital equivalent of bringing indoor plumbing to the campus." 5In spring 2001, an enterprise DAM system was considered for inclusion in the university infrastruc ture.Upon completion of a limited proofofconcept project, a crosscampus team developed the request for proposals (RFP) for the DAMS Living Lab, which was issued in July 2002 and subsequently awarded to IBM and Ancept.In August 2003, hardware and software installation began in the Living Lab. 6 By 2006, the project changed its name to BlueStream to appeal to the grow ing mainstream user base. 7ix academic and two support units agreed to partner in the pilot: ■ Background of the Living Lab: U-M enterprise DAM system project An enterprise project such as the Living Lab at UM can have significant impact on an institution's teaching and learning activities by allowing all faculty and students easy yet secure access to media assets across the entire campus.Such extensive impact can only be obtained by overcoming numerous and varied obstacles and by docu menting actual implementation experiences employed to overcome those challenges.Enterprise DAM system vendors such as Stellent, Artesia, and Canto list clients from many different industry sectors, including gov ernment and education, but provide no detailed case studies on their Web sites. 8Information regarding the status of enterprise DAM system projects and specific issues that arose during implementation is difficult to find.Information publicly available for enterprise DAM system projects in higher education is usually in the form of white papers or proposals that do not cover the actual implementations. 9Given the high degree of interest and the number of pilot projects announced in recent years, this shortcoming has prompted the writing of this article, which presents the most important lessons learned dur ing the first phase of the Living Lab pilot project with the hope that these experiences will be valuable to other academic institutions considering similar projects.
As part of its core mission, UM strives to meet the teaching and learning needs of the entire campus.Thus, the Living Lab pilot solicited participation from a diverse crosssection of the university's departments and units with the goal of evaluating the use of varied teaching and learning assets for the system.From the beginning, it was expected that this system would handle assets in many different forms, such as digital video or digitized images, and also accommodate various organizational schemas and metadata for different collections.This sets the UM enterprise DAM system apart from projects that focus on only one type of collection or define a large monolithic metadata schema for all assets.
Data were gathered through interviews with asset providers, focus groups with potential users, and a review of the relevant literature.A number of barriers were identified during the pilot's first phase.While there were some technical barriers, the most signifi cant barriers were cultural and organizational ones for which technical solutions were not clear.Perhaps the most significant cultural divide was between the culture of academia and the culture of the commercial sector.Cultural and organizational assumptions from com mercial business practices were embedded in the design of the products initially used in the Living Lab imple mentation.Thus, an additional implementation chal lenge was determining which issues should be resolved through technical means, and which should be solved by changing the academic culture.This is expected to be an ongoing challenge.
■ Architecture (building the infrastructure) An enterprise DAM system in an academic community such as UM needs to support a wide variety of services in order to meet the numerous and varied teaching, research, service, and administrative functions.Figure 1 illustrates the services that are provided by an enterprise DAM system and concurrently demonstrates its com plexity.The left column, Process, lists a few of the media processes that various producers will use prepare their media and subsequent ingestion into the enterprise DAM system; the middle column, Manage, demonstrates the various functions of the enterprise DAM system; while the third column, Publish, lists a subset of the publishing venues for the media.
Because an enterprise DAM system supports a variety of rich media, a number of software tools and workflows are required.Figure 2 illustrates this complexity and describes the architecture and workflow used to add a video segment.The organization of figure 2 parallels that of figure 1.The left column, Process, indicates that Flip Factory by Telestream is used to convert digital video from the original codec to one that can be used for play back. 10In addition, VideoLogger by Virage uses media analysis algorithms to extract key frames and time codes from the video as well as to convert the speechtotext for easy searching. 11The middle column, Manage, illustrates tools from IBM that help create rich media as well as tools from Stellent, such as its Ancept Media Server (AMS), that store and index the rich media assets. 12The third column, Publish, illustrates two examples of how these digital video assets could be made available to the end user.One strategy is as a real video stream using Real Network's Helix Server, and the other as a QuickTime video stream using IBM's VideoCharger. 13A thorough discussion of all of the software and hardware that make up UM's DAM system is beyond the scope of this article.However, a list of the software components with links to their associated Web sites is provided in figure 3.
From the beginning the Living Lab pilot aimed for a diverse collection of assets to promote resource discovery and sharing across the university.Figure 4 illustrates how the Living Lab is expected to fit into the varied publishing venues that comprise the campus teaching and learning infrastructure.Existing storage and network infrastruc tures are used to deliver media assets to various software systems on campus.The Living Lab is used to streamline the cataloging, searching, and retrieving processes encoun tered during academic teaching and research activities.
The following example describes how the enterprise DAM system fits into the future campus cyberinfrastruc ture.A faculty member in the School of Music is a jazz composer.One of her compositions is digitally stored in the enterprise DAM system along with the associated metadata (cataloging information) that will allow the piece to be found during a search.That single audio file is then found, accessed, and used by five unique publish ing venues-the course Web site, the university Web site, a radio broadcast, the music store, and the library archive.The faculty member uses the piece in her jazz interpreta tion course and thus includes a link to the composition on her Sakai course Web site. 14When she receives an award, the UM issues a press release on the UM Web site that includes a link to an audio sample.Concurrently, Michigan Radio uses the enterprise DAM system to find the piece for a radio interview with her that includes an audio segment. 15Her performance is published by Block M Records, UM's Webbased recording label, and, lastly, the library permanently stores the valuable piece in its institutional archive, Deep Blue. 16Metadata (managing assets within the academic model) The vision for enterprise DAM at UM is for digital assets to not only be stored in a secure repository, but also be findable, accessible, and usable by the appropriate persons in the university community in their academic endeavors.Information about these assets, or metadata, is a crucial component of fulfilling this vision.An important To help answer this question, potential asset provid ers were interviewed regarding their current approach to metadata, such as if they used a particular schema and how well it met their purposes.Not surprisingly, asset providers had widely varied metadata implementations.While the assets intended for the Living Lab pilot all had some metadata, the scope and granularity varied greatly.Metadata storage and access methods also varied, ranging from databases implemented using commercial database products and providing Web frontends, to a combination of paper and spreadsheet records that had to be consulted together to locate a particular asset.The assets to be used in the Living Lab pilot consisted primarily of high and lowresolution digital images and digitized video.These interviews also generated a number of requirements for any potential Living Lab metadata schema.It was deter mined that the schema should be able to: ■ describe heterogeneous collections at an appropriate level of granularity and detail, allowing for domain specific description needs and vocabularies; An examination of the literature showed a general consensus that no single metadata standard could meet the requirements of heterogeneous collections. 17Projects as diverse as PB Core and VIUS at Penn State adopted the approach of drawing from multiple existing metadata standards. 18Their approaches differ in that PB Core is a combination of selected metadata elements from a num ber of standards plus additional elements unique to PB Core, while VIUS opted for a merged superset of all the elements in the standards selected.
In interviews with asset providers (usually faculty), cataloging backlog and the lack of personnel for gen erating and entering metadata emerged as consistent problems.There was concern that an overly complex or specialized schema would aggravate the cataloging back log by making metadata generation timeconsuming and cumbersome.Budgetary constraints made hiring pro fessional metadata creators prohibitive.Another aspect of the personnel problem was that adequate descrip tion required subject specialists who were, ideally, the resource authors or creators.But subject specialists, while familiar with the resources and the potential audience for them, may not be knowledgeable of how to produce highquality metadata, such as controlled vocabularies or consistent naming formats.
To address these issues, the more simple and straight forward indexing process offered by Dublin Core (DC) was selected as the starting point for the metadata schema in the Living Lab. 19DC was originally developed to sup port resource discovery of a digital object, with resource authors as metadata creators.DC is a relatively small standard, but is extensible through the use of qualifiers.It has been adopted as a standard by a number of standards organizations, such as ISO and ANSI.A body of research exists on its use in digital libraries and its efficacy for authorgenerated metadata, and there are metadata crosswalks between DC and most other metadata stan dards.A number of other subjectspecific standards were also examined for more specialized description needs and controlled vocabularies: VRA Core, IMS Learning Resource MetaData Specification, and SNODENT. 20n the end, the project leaders elected to adopt a rather novel approach to metadata by not defining one metadata schema for all assets.By taking advantage of the power of multiple approaches (for example, PB Core for mixand match, and VIUS for a merged superset) each collection can have its own schema as long as it contains the ele ments of a more general, lowestcommondenominator schema.This overall schema, UM_Core, was defined based on DC.
The elements are prefixed with DC or UM to specify the schema origin.UM_Publisher and UM_AlternatePublisher identify who should be contacted about problems or ques tions regarding that particular asset.UM_SecondarySubject is a crosscollection subject classification schema devel In adopting such an approach to metadata, metadata creation is seen not as a oneshot process, but a collaborative and iterative one.For example, on initial ingestion into the Living Lab, the only metadata entered for an image may be DC_Title, DC_Date, and UM_Publisher.Additional meta data may be entered as users discover and use the asset, or as input from a subject specialist becomes available.
The discussion so far has focused on metadata pro duced with human intervention.A number of metadata elements can be obtained from the digital objects through the use of software.In an enterprise DAM system, this is referred to as automatically generated metadata and is what can be directly obtained from a computer file such as file name, file size, and file format.This type of metadata is expected to play a larger role as an increasing propor tion of assets will be born digital and come accompanied by a rich set of embedded metadata.For example, images or video produced by current digital cameras contain exchangeable image file format (EXIF) metadata, which include such information as image size, date produced, and camera model used.When available, the Living Lab presents automatically generated metadata to the user in addition to the elements in UM_Core.
Thus, asset metadata in the Living Lab can be pro duced in two ways: automatically generated through a tool such as Virage VideoLogger in the case of video, or entered by hand through the current DAM system inter face. 21In addition, if metadata already exist in a database format, such as FileMaker, this can be imported once the appropriate mappings are defined. 22ideoLogger, a video analysis tool for digital video files, can extract video key frames, add closed captions, determine whether the audio is speech or music, convert speech to text, and identify (through facial recognition) the speaker(s).These capabilities allow for more sophis ticated searching of video assets compared to the cur rent capabilities of search engines such as Google.Some degree of contentbased searching can now be done, as opposed to searching that relies on the title and other textual description provided separately from the video itself.For the pilot, particular interest was expressed in the speech recognition capability of VideoLogger.VideoLogger generates a timecoded text of spoken key words with 50 to 90 percent accuracy.The result is not nearly accurate enough to generate a transcript, but does indeed provide robust data for searching the content of video.Given the diversity of assets in the Living Lab, it is clear that the university can utilize lowcost keyword analysis to enhance search granularity as well as the more expensive, fully accurate handprocessed transcript.

■ Workflow examples
Two instructional challenges demonstrate how an enter prise digital asset management system can provide a solution to instructional dilemmas and how a unique workflow needs to be created for each situation.The chal lenges related to each project are described.

school of Dentistry the Educational Dilemma
The UM School of Dentistry uses standardized patient instructors (SPIs) to assess students' abilities to interact with patients.Carefully trained actors play carefully scripted patient roles.Dental students interview the patients, read their records, and make decisions about the patients' care, all in a few minutes (see figure 6).Each session is video recorded.Currently, SPIs grade each student on predeter mined criteria, and the video recording is only used if a student contests the SPIs' grade.Ideally, a dental educator should review each recording and also grade each student.However, the UM class size of 105 dental students causes a recordingbased grading process to be prohibitively expensive in terms of personnel time.In addition, the use of digital videotape makes it difficult for the recorded sessions to be made available to the students.Because the tapes are part of the student's record, they cannot be checked out.If a student wants to review a tape, she or he must make an appointment and review it in a supervised setting.

Living Lab solution
The UM School of Dentistry's Living Lab pilot attempted simultaneously to improve the SPI program and lower the cost of faculty grading SPI sessions through three goals: 1. use speechtotext analysis to create an easily searched transcript; 2. streamline the recording process; and 3. make the videos available online for student review.
Each of these challenges and the current results are summarized.

speech-to-text analysis
It was hypothesized that an effective speechtotext anal ysis of the SPI session could enable a grader quickly to locate video segments that: (1) represented student dis cussion of specific dental procedures; and (2) contained student verbalizations of key clinical communication skills. 23In summer 2005, nine SPI sessions were recorded and a comparison between manual transcription and the automated speechtotext processes was conducted.The transcribed audio track was manually marked up with timecoded reference points and inserted as an annota tion track to the video.Those same videos also were ana lyzed through the Video Logger speechtotext service in the Living Lab, resulting in an automatically generated, timecoded text track.Lastly, six keywords were selected that, if spoken by the student, indicated the correct use of either a dental procedure or good communication skills.Keyword searches were conducted on both the manual transcription and the speechtotext analysis.Three results were calculated on the key word searches of both versions of all nine recorded sessions.They were: (1) the number of successful keyword searches; (2) the number of successful search results that did not actually contain the keywords (false positives); and (3) the time required to complete the manual transcrip tion and texttospeech analysis of the recordings.The results demonstrated that the speechtotext analysis matched the manual transcription 20 to 60 percent of the time.Also, the speechtotext process resulted in a false positive less than 10 percent of the time.Lastly, the time required to complete the speechtotext analysis of a session was two minutes, while the average time required to complete a manual transcription of the same session was 180 minutes.While not perfect, the results are encouraging that manually transcribing the audio is no longer necessary.Improvements are being made to the clinical environment and microphones so that a higherquality recording is obtained.It is anticipated that those changes combined with improved software will improve the results of the speechtotext analysis sufficiently so that automated keyword searches can be conducted for grading purposes.

streamlining the recording process
Scale is a significant challenge to capturing 105 SPI inter actions in a short amount of time.Two to three weeks are required for the entire class of 105 students to complete a series of SPI experiences, with as a many as four concur rent sessions at any given time.In summer 2006, it was decided to record 50 percent of one class.Logistically, one camera operator could staff two stations simultane ously.The stations had to be physically close enough for a oneperson operation, but not so close that audio from the adjacent session was recorded.The optimal distance was about thirty to thirtyfive feet of separa tion.Staggering the start times of each session allowed the camera operator to make sure each was started with optimal settings.Since the results of the speechtotext analysis were linked to the quality of the equipment used, two prosumer miniDV cameras with professional quality microphones and tripods also were purchased.

student availability
An important strength of Living Lab is the ability to make the assets both protected and accessible.The current itera tion does not have an interface for usercreated access con trol lists (ACL), instead they need to be created by a systems administrator.Once a systems administrator has created an ACL, academic technology support staff can add or subtract people.To satisfy Family Educational Rights and Protection Act regulations, a separate ACL is needed for each student for the SPI project. 24Currently, the possibility of including the SPI recordings and their associated transcriptions as ele ments of an ePortfolio is being explored. 25In the meantime, students can use URL references to include these videos and transcripts in such Webbased tools as ePortfolios and course management systems.

Discussion
As the challenges of improving speechtotext analysis, recording workflow, and usercreated ACLs are overcome, the SPI program will be able to operate at a new and previ ously unimagined level.A more objective keyword grad ing process can be instituted.Students will be easily able to search through and review their sessions at times and locations that are convenient for them.Living Lab also will allow students to view their ePortfolio of SPI interactions and witness how they have improved their communica tion skills with patients.For the first time in healthcare education, a clinician's communication skills, such as bedside or chairside manner, will be able to be taught and assessed using objective methods.

processing classroom records
The classroom records used in the pilot were processed in three main ways, producing three different types of products: ■ Preservation copies are highquality formats of the classroom records with minimal loss of digital infor mation that can be read by modern computers with standard software.These files are given standardized filenames, cleaned of artifacts and minor irregu larities, and deidentified (that is, digitally altered to remove any information that could reveal the identity of the students and, in some cases, of the teachers).

■
Working copies are lowerquality versions of the preservation copies that are still sufficient for print ing or displaying and viewing.Trading some degree of quality for smaller file sizes and thus data rates, the working copies are easier for people to use and share.Additionally, these files are further devel oped to enhance usability: videos are clipped and composited to feature particular episodes; videos also are subtitled, flagged with chapter markers (or other types of coding), and embedded with links for accessing other relevant information; images of stu dent and teacher work are organized into multipage PDFs with bookmarks, links, and other navigational aids; and all files are embedded with metadata for aiding their discovery and revealing information about the files and their contents.

■
Distribution copies are typically similar in quality to the working copies but are often integrated into other documents or with other content; they are labeled with copyright information and statements about the limitations of use.They are, in many cases, edited for use on a variety of platforms and copy protected in small ways (for example, Word and PowerPoint files are converted to PDFs).
The Living Lab was found to support this processing of classroom records in two important ways.First, the system allowed for the setup and use of workflows that enabled undergraduate students hired by the project to upload processed files into the system and walk through a series of quality checks, focused on different aspects of the products.So, for example, when checking the preservation copies, one person was assigned to check the preservation copy against the actual artifact to make sure everything was captured adequately and that the resulting digital file was named properly ("quality check 1").Another individual was assigned to make sure the content was cleaned up properly and that no identifying information appeared anywhere ("quality check 2").And finally, a third person checked the file against the meta data to make sure that all basic information about the file was correct ("quality check 3").Files that passed through all checks were organized into collections accessible to project members and others ("organize").Files that failed along the way were sent back to the beginning of the workflow (the "drawing board"), fixed, and checked again (see figure 7).Second, Living Lab allowed asset and collection development to be carried out collaboratively and itera tively, enabling different individuals to add value in dif ferent ways over time.Undergraduate students did much of the initial processing and checking of the assets; skilled staff members converted subtitles into speech metadata housed within Living Lab; and, eventually, project faculty and graduate students will add other types of analytic codes and content specific metadata to the assets.

Distribution and protection of classroom records
In addition to supporting the production of various types of assets and collections, the Living Lab supported the distribution and protection of classroom records for use in education settings both at UM and other institutions.For example, almost fifteen hours of classroom videos from a thirdgrade mathematics class were made acces sible to and were used by instructors and students in the College of Education at Michigan State University.In a different context, approximately ten minutes of classroom video was made available to instructors in mathematics departments at Brigham Young University, the University of Georgia, and the City College of New York to use in courses for elementary teachers.
Each asset (and its derivatives) housed within Living Lab has a URL that can be embedded within Web pages and online coursemanagement systems, allowing for a great deal of flexibility in how and where the assets are pre sented and used.At the same time, each call to the server is checked and, when required, users are prompted to authen ticate by logging in before any assets are delivered.This has great potential for easily, seamlessly, and safely integrating Living Lab assets into a variety of Web spaces.Although this feature has indeed allowed for a great deal of flexibility, there were and continue to be challenges with creating an integrated and seamless experience for School of Education students and their instructors.For example, depending on a variety of factors, such as user operating systems and Web browser combinations, users might be prompted for multiple logins.Additionally, the login for the Living Lab server can be quite unforgiving, locking out users who fail to login properly in the first few tries and providing limited communication about what has occurred and what needs to be done to correct the situation.

Discussion
During the Living Lab pilot a number of workflow chal lenges were overcome that now allow numerous and varied types of media related to classroom records to be ingested into Living Lab, and derivatives created.This demonstrates that Living Lab is ready for complex media challenges associated with instruction.However, the next challenge of delivering easily and smoothly to others still remains.Once authentication and authorization is con ducted using single signon techniques that allow users to access assets securely from Living Lab through other systems, assets will be able to be incorporated into Web based materials and used to enhance the instruction of teachers in ways that have yet to be conceived.

■ Privacy, intellectual property, and copyright
During the course of the pilot, a number of issues emerged.Among these were some of the most critical issues that institutions considering embarking on a similar asset man agement system need to address.These issues are: Up to this point, enterprise DAM systems had been developed and used primarily by commercial enterprisesfor example, CNN and other broadcasting companies.Using a product developed by and for the commercial sec tor brought to the fore the cultural differences between the academy and the commercial sector (see figure 8).The first three issues in the previous list are related to the differing cultures of commercial enterprise and academia.These issues are addressed below.The fourth and fifth issues are addressed in the section "Other Important Issues."privacy Videos of medical procedures can be of tremendous value to students.In their own words, "Watching is different from reading about it in a textbook."But subjects have the right to retract their consent regarding the use of their images or treatment information for educational purposes.This creates a dilemma: if other assets have been cre ated using it, do all of them have to be withdrawn?For drawing board → quality check 1 → quality check 2 → quality check 3 → organize example, if a professor included an image from the univer sity's DAM system in a classroom PowerPoint or Keynote presentation, and subsequently included the presentation in the university's DAM system, what is the status of this file if the patient withdraws consent for use of her or his treatment information? 26When must the patient's request be fulfilled?Can it be done at the end of the semester, or does it need to be completed immediately?If the request must be fulfilled immediately, the faculty member may not have sufficient time to find a comparable replacement.Waiting until the end of the semester helps balance patient privacy with teaching needs.In either case, files must be withdrawn from the enterprise DAM system and links to those files removed.Consent status and asset relationships must be part of the metadata for an asset to handle such situations.Consideration must be given to associating a digital copy of all consent forms with the corresponding asset within an enterprise DAM system.

intellectual ownership and author control of materials
Authors' rights, as recognized by the Berne Convention for the Protection of Literary and Artistic Works, have two components. 27One, the economic right in the work, is what is usually recognized by copyright law in the United States, being a property right that the author of the work can transfer to others through a contract.The other component-the moral rights of the author-is not explicitly acknowledged by copyright law in the United States and thus may escape consideration regarding ownership and use of intellectual property.Moral rights include the right to the integrity of the work, and thus come into play in situations where a work is distorted or misrepresented.Unlike economic rights, moral rights cannot be transferred and remain with the author.In a university setting, the university may own the economic right for a researcher's work, in the form of copyright, but the researcher retains moral rights.
The following incident illustrates what can happen when only property rights are taken into account.A digital video segment of a medical procedure was being shown as part of a Living Lab demo at a university IT showcase.Because the UM held the copyright for that particular videotape, no problems were foreseen regarding its usage.A faculty member recognized the video as one she had cre ated several years ago and expressed great concern that it had been used for such a purpose without her knowledge or consent.The concern arose from the fact that video showed an outdated procedure.While the faculty member continued to use this video in the classroom, she felt this was different from having it available through the Living Lab.In the classroom, the faculty member alerted students to the outdated practices during the viewing, and she had full control over who viewed it.The faculty member felt she lost this control and additional clarification when the video became available through Living Lab.That is, her work was now misrepresented and her moral rights as an author were violated.

Digital rights management and copyright
In the academic world, digital rights management (DRM) is becoming a necessary component in disseminating intellectual products of all forms. 28However, at this time there are few standards and no technical DRM solution that works for all media on all platforms.Therefore, UM has elected to use social rather than technical means of managing digital rights.The Living Lab metadata schema provides an element for rights statements, DC_Rights.These metadata, combined with education of the univer sity community about copyright, fair use, and the highly granular access control and privileges management of the system, provide the community with the knowledge and tools to use the assets ethically.
The university can establish rights declarations to use in the DC_Rights field as standards are developed and prec edent is established in the courts.These declarations may include copyright licenses developed by the university legal counsel as well as those from the Creative Commons. 29

current solution-access control lists
A clear difference between the cultures of commercial enterprises and academia emerged regarding access to assets, administered through ACLs. 30  who is allowed to access an asset and how they can use it.In commercial settings, access to assets is centrally managed, while in academia, with its complex set of intellectual and copyright issues, it is preferable to have them managed by the asset holders.University users repeatedly asked for the ability to define ACLs for each asset in the Living Lab.Currently, end users and support staff cannot define ACLs-only system administrators can create them.The middleware for userdefined ACLs has been fully developed, and the user interface for user defined ACLs will be made available in the next version.This capability is important in the academic envi ronment because the composition of group(s) of people requiring access to a particular asset is fluid and can span many organizational boundaries, both within and outside the university.A research group owning a collection of assets may want to restrict access for various reasons, including requirements set forth by an institutional review board (IRB, a university group that oversees research projects involving human subjects), or regulations such as the Health Insurance Portability and Accountability Act of 1996, which addresses patient health information privacy. 32The research group will want flexible access control, as research group members may collaborate with others inside and outside the university.The original IRB approval may specify that confidentiality of the subjects must be maintained, and collected data, such as video or transcripts, can only be viewed by those directly involved in the research project and cannot be browsed by other researchers not involved in the study or the public at large.In another situation, a collection of art images may only be viewed by current students of the institution, thus requiring a different ACL.
This situation is still open to interpretation.Some say patient consent regarding the use of information for instructional purposes cannot be withdrawn for the use of existing information at the home institution.They can only withdraw it for the use of future assets.Others may feel that patients can withdraw permission for the use of their patient assets.

other important issues uncataloged materials backlog
What emerged from interviews and focus groups with content providers was that while there was no lack of assets they would like to see online, a large proportion of these assets had never been cataloged or even sys tematically labeled in some form.This finding may be attributed in part to the pilot focusing on existing assets that have previously not been available for widespread sharing-such as the files stored on faculty hard disks and departmental servers-only known to a favored few.Owners or creators of these materials had not consciously thought about sharing these materials or making them available to others.Librarians, in contrast, have devel oped systems and practices to ensure the findability of materials that enter the library.
Asset owners were more than willing to have the assets placed online, but did not have the time or resources to provide the appropriate metadata.Hiring personnel to create the metadata is problematic, as there is a limit to the metadata that can be entered by nonexperts, and experts often are scarce and expensive.For example, for a collection of oral pathology images of microscopic slides, a subject expert must provide the diagnoses, stain, magnification, and other information for each image.Without these details, merely putting the slides online is of little value, but these metadata cannot be provided by laypeople.Collaborative metadata creation, allowing multiple metadata authors and iterations, may be one solution to this problem.
A number of studies indicate that both organiza tional support and userfriendly metadata creation tools are necessary for resource authors to create high quality metadata. 33Some of the backlog may be resolved through development of tools aimed at resource authors.In addition, increased use of digital file formats with embedded metadata may contribute to reducing future backlog by requiring less human involvement in meta data creation.
Faculty need to be taught that metadata raises the value and utility of assets.As they come to understand the essential role metadata plays, they, too, will invest in its creation.

user interface and integration with other systems
An enterprise DAM system has two basic types of uses: by producers and by users.Producers tend to be digital media technologists who create the digital assets and ingest them into the enterprise DAM system.The users are the faculty, students, and staff who use these digital assets in their teaching, learning, or research.The research and development version of the enter prise DAM system, Living Lab, works well for digital asset producers, but not for the users of these digital assets.Ingestion and accessing processes are quite complex and are not currently integrated with other campus systems, such as the online library catalog or the Sakaibased, campuswide course management sys tem, CTools. 34Digital producers who are comfortable with complex systems are able to ingest and access rich media.However, users have to log onto the enterprise DAM system and navigate its complex user interface.The level of complexity of accessing the media can cre ate a barrier to adoption and use.If the level of complex ity for accessing the assets is too high for users, then the system also is too complex to expect users to contribute to the ingestion of digital assets.
In both student and faculty focus groups there was concern about the technical skills needed for faculty use of an enterprise DAM system in the classroom.Ideally faculty should be able to incorporate assets seamlessly from the enterprise DAM system to their classroom mate rials, such as PowerPoint or Keynote presentations.Then, the presentations created on their computers should dis play without glitches on the classroom system.Obviously faculty members cannot be expected to troubleshoot in the classroom when display problems occur.
If the enterprise DAM system is perceived as difficult to use, or as requiring a lot of troubleshooting by the user, this will discourage adoption by the faculty.This creates additional demands on the enterprise DAM system, and potential additional IT staffing demands for the academic units wanting to promote enterprise DAM system use.When a problem is experienced in the classroom, the departmental IT support, not the enterprise DAM system support team, will be the first to be called.
Ideally, an enterprise DAM system should be linked to the campus IT infrastructure such that users or con sumers do not interact with the DAM system itself, but rather through existing academic tools, such as the library gateway, course management system, or departmental Web sites.Having to learn a new system could be a sig nificant barrier to use for many potential DAM system users in academia.

■ Conclusions and lessons learned
The vision of a DAM system that would allow faculty and students easy yet secure access to myriad rich media assets is extremely appealing to members of the academy.Conducting the pilot projects revealed numerous techni cal and cultural problems to resolve prior to achieving this vision.The authors anticipate that other institutions will need to address these same issues before undertaking their own enterprise DAM system.

using commercial software developed in academia
During the course of the Living Lab pilot, the differ ences between academia and the commercial sector proved to be a significant issue.Assumptions about the organizational culture and work methods are built into systems, often in a tacit manner.In the case of the initial iteration of the Living Lab, these assumptions were those of the corporate world, the primary clients of the commercial providers as well the environment of the developers.UM project participants, meanwhile, brought their own expectations based on the reality of their work environment in academia.Universities do not have a strict hierarchical structure, with each aca demic unit and department having a great degree of local control.Academia also has a culture of sharing, where teaching or research products are often shared with no payment involved, other than acknowledgment of the source.Thus, there was a process of mutual edu cation and negotiation regarding what was and was not acceptable in the enterprise DAM system implementa tion.This difference of cultures first manifested itself with ACLs.In the initial implementation, an ACL could be defined only by a system administrator.This was a showstopper for the UM participants, who thought that asset providers themselves would be able to define and modify the ACL for any particular asset.A centralized solution with a single owner of the assets (the company), which is acceptable in the corporate environment, is not acceptable in a university environment, where each user is consumer and owner.Defining who has access to an asset can be a complex problem in academia, since this access is a moving target subject to both departmental and institutional constraints.

Libraries and librarians
The traditional role of libraries is one of preserving and making accessible the intellectual property of all of humanity.With each new advance in information tech nology, such as DAM systems, the role of libraries and librarians continues to evolve.This pilot highlighted the role and value of librarians skilled in metadata develop ment and assignment.Without their expertise and early involvement, there would have been no standard method of indexing assets, thus preventing users from finding useful media.Also, the project reinforced two reasons for encouraging asset creators to assign metadata at the asset creation point instead of at the archival point.One, this ensures that metadata are assigned when the content expertise is available.It is very difficult for producers to assign metadata retrospectively, and the indexing information may no longer be available at the point of archive.Two, metadata assignment at the point of asset creation helps to ensure consistent metadata assignment that lends itself to automated solutions at the time of archiving. 35Thus, while their role in digital asset man agement systems continues to evolve, the authors predict that the librarians' role will evolve around metadata, and that libraries will start to become the archive for digital materials.It is anticipated that librarians will work with technical experts to develop workflows that include the automated metadata assignment to help faculty routinely add existing and new collections of assets to the system.One example of such a role is Deep Blue at the University of Michigan.Deep Blue is a digital framework for pre serving and finding the best scholarly and artistic work produced at the University.

production productivity
New technical complexities emerge with each new asset collection added to the UM system.New workflows as well as richer software features continue to be developed to meet newly identified integration and user interface needs.As the Living Lab experience advances, techni cal barriers are eliminated and new workflows auto mated.The authors anticipate that, eventually, automated workflows will allow faculty and staff to routinely use digital assets with a minimum of technical expertise, thus decreasing the personnel costs associated with the use of rich media.For the foreseeable future, however, techni cally knowledgeable staff will be required to develop these workflows and even complete a significant amount of the work.

academic practice
The more delicate and challenging issue is educating fac ulty on the value and power of digital assets to improve their research and teaching.DAM is a new concept to fac ulty, and it will only become useful when integrated into their daily teaching and research.This will happen as fac ulty members become more knowledgeable and increase their comfort in the use of digital assets.The dental case study demonstrates that an improved student experience can be provided with such an asset management system, while the education case study demonstrates that a com plex set of authentic classroom materials can be orga nized and ingested for use by others.These case studies are only two examples of the unanticipated outcomes that result from the use of digital assets in education.The authors predict that as more unanticipated and innova tive uses of digital assets are discovered, these new uses will, in turn, lead to increased academic productivity-for example, teaching more without increasing the number of faculty, students teaching each other with rich media, smallgroup work, and projectbased learning.The list of possibilities is endless.
As the Living Lab evolved from a research and development project into the implementation project known as BlueStream, it has become an actual classroom resource.This article described myriad issues that were addressed so that other institutions can embark on their own enterprise DAM systems fully informed about the road ahead.The remaining technical issues can and will be resolved over time.The greatest challenges that remain are being discovered as faculty and students use BlueStream to improve teaching, learning, and research activities.The success of BlueStream specifically, and enterprise DAM systems in general, will be determined by their successes and failures in meeting the needs of faculty and students.

Figure 1 .
Figure 1.Component services of the Living Lab

Figure 3 .
Figure 3. Software used in the Living Lab

■
allow metadata entry by nonspecialists; ■ enable searches across multiple subject areas and col lections; ■ provide provenance information for the assets; and ■ provide information on authorized uses of the assets for differing classes of users.

Figure 4 .
Figure 4.The enterprise DAM system as the future campus infrastructure for academic venues

Figure 5 .
Figure 5.The u-M enterprise DAM system metadata scheme uM_Core using records of practice for research and professional educationClassroom documentation plays a significant role in educational research and in the professional education of teachers at the UM School of Education.Collections of videos capturing classroom lessons, smallgroup work, and interviews with students and teachers-as well as other classroom records, such as images of student work, teacher lesson plans, and assessment documents-are basic to much of the research that takes places in the School of Education.However, there also is a large and increasing demand to use these records from real class rooms for educational purposes at the UM and beyond, creating rich media materials for helping preservice and practicing teachers learn to see, understand, and engage in important practices of teaching.This desire to create widely distributed educational materials from classroom documentation raises two important challenges: first, there is the important challenge of protecting the identity of children (and, in some cases, teachers); and second, there is the difficult task of ensuring that the classroom records can be easily accessed by individuals who have permission to view and use the records while being inac cessible to those without permission.One research and materials development project at the UM School of Education has been exploring the use of Living Lab to support the critical work of processing classroom records for use in research and in educational materials, and the distribution and protection of class room records as they are integrated into teacher educa tion lessons and professional development sessions at the UM and other sites in the United States.The findings and challenges of these efforts are summarized below.

Figure 6 .
Figure 6.A dental student interviewing an SPi.
author control of materials; ■ digital rights management and copyright; ■ uncataloged materials backlog; and ■ user interface and integration with other campus systems.

Figure 8 .
Figure 8. Differences between commerical and university uses of a DAM system.
An ACL specifies