# Presentation: 201892

## METS at UCB

- Themes in the Implementation of METS
- Rick Beaubien
- UC Berkeley Library

## METS Themes

- METS creation
- Gathering metadata: structural, descriptive, administrative
- Generating METS objects
- METS Repositories
- Providing search access to METS objects
- Presenting METS objects

**Notes:**
I am going to organize this examination our implementation of METS in the UC Berkeley Library on what seem to me to be the most common and basic METS Implementation themes or issues.  It will be sort of a METS Meat and Potatos METS if you will—quite what you should expect  from an Iowa Farm boy.

I’ll start by taking a look at METS creation issues, and how we’re going about gathering...

Second, I’ll talk some about METS repository issues: providing search access to objects in our METS repositories, and presenting METS objects to the end users.

Finally, I want to look some at the METS sharing issues we face: not only sharing METS objects between METS repositories, but also across standards and communities.

## METS Themes (2)

- METS sharing
- Sharing METS objects between METS Repositories
- Sharing METS objects across standards and communities.

## Brief History: 3 eras

- Paleozoic: pre-MOA2 (pre-1997)
- 1994: California Heritage; preliminary DB
- 1996: Honeyman Collection: Desc. MD elements defined
- Mesozoic: MOA2 (1997-2001)
- Consistent, non-central DB: struct., desc. & tech. md
- MOA2 presentation tool
- Cenozoic: METS (2001-2004)
- Central database: struct., desc. &  tech. md
- Expanding, adapting MOA2 tools

**Notes:**
Before I get into the themes proper I need to give you a little historical context for our METS work at UCB.  So, venture with me, if you will, back before the emergence of man, before the dinosaurs roamed, before the Cambrian explosion, back to when life on earth was but the promise of a few key molecules in a prebiotic stew, all the way back to 1994 when a digital object standard was but a gleam in Jerry McDonough’s eye...

In 1994 UC Berkeley Library embarked on its first big digitization project: California Heritage
Goal was to digitize some of 30,000 images pertaining to California History from The Bancroft Library’s pictorial materials collection.
In terms of Digital Library Standards, the EAD was in the process of being developed during this same period, but the problem of encoding the end digital objects themselves had not been addressed.  
Preliminary metadata gathering database developed: 
	Some Collection level information (EAD)
	Limited descriptive metadata
	Image tracking md
	No structural metadata:  (mainly single-image, pictorial materials)

The next big development in our DL work took place in conjunction with our digitization of the Honeyman Collection of Early California and Western America Pictorial Materials:  digitized under the umbrella of California Heritage.
For this project we developed a md gathering database with a substantial descriptive metadata element set
	Basis for descriptive metadata element set: 
		cdwa (categories for the description of Works at Art), vra-core, REACH

This metadata gathering database, though greatly expanded over the preliminary California Heritage database still made no provision for structural metadata; and was primarily useful for single image pictorial materials.  

Making of America II project sponsored by DLF and led by UC Berkeley had a big impact on on digital library work at UCB.
	MOA2.DTD: provided an encoding schema for complex digital objects with structural, descriptive, and administrative metadata components. Predecessor and basis for METS.
	Expanded metadata gathering database developed during pre-MOA2 phase to include substantial structural and technical metadata component (This was still a non-centralized database, however.  The database was developed in Microsoft Access; and we in fact issued an edition of the database conforming more or less to the same specifications for each participant involved in a project). 
	Developed a java-based MOA2 digital object presentation tool that allowed users to view and navigate MOA2 encoded digital objects.

Starting in February of 2001, we participated in the DLF sponsored initiative to turn the MOA2.DTD into METS, and when released METS superseded MOA2 as our official digital object encoding standard. In conjunction with our adoption of METS we started to:
	Develop a centralized metadata gathering database based on MOA2 work.  This database is designed to be METS compatible.
	Expand and adapt the tools we had started developing under MOA2 to work for METS.

## METS Projects at UCB

- Archival collections: Project-based, grant-funded initiatives
- New projects
- Data Rescue projects
- Stored materials: Online access to tables of contents
- Technical Reports: heir of Dienst

**Notes:**
Work is currently in progress on three main categories of METS projects in the UCB Library:
Archival collections, Stored materials, and Technical Reports.
The Digitization of archival materials represents by far the largest METS-based project area:
Bancroft’s vast collection of archival materials, chinese stone rubbings, historical maps, architectural design materials held by the Environmental Design Archive
Many of the projects are done under auspices of Online Archive of California, and METS output will be deposited with OAC. UCB METS objects will also reside in our own METS repository.
In addition to new projects which are METS-based from the start, we have legacy digital materials of various kinds that we need to convert to METS:  These include:  MOA2 objects, Access databases, SGML Finding Aids

Stored Materials Project:
Project headed by Michael Conkin to scan and ocr the table of contents of books in our off-campus storage facility; make these available as METS objects from on online catalog.  Also make them independently searchable via ocr’d text.  Goal: help patrons select materials from storage that will be most useful to them. 

Technical reports:
Replacement for old Dienst infrastructure
Garey Mills, the project leader, is working to create METS objects for the technical reports coming out of various university research projects (both past and future). 
These will reside in a METS repository that will be independently searchable as well as available for OAI harvesting. 

## METS Creation at UCB

- Centralized approach
- Centralized database with associated metadata input and METS generation modules
- Dispersed approach
- Perl scripts—mostly ad hoc—extract necessary metadata from multiple sources

**Notes:**
With this context in mind, lets turn to the core METS Implementation themes.  I’ll start, quite naturally with METS Creation:  There is alas no spontaneous generation in the digital library world.  In order to get something out in general you have to put something in.  I am reminded a bit of Tom Lehrer’s “Life is like a sewer” analogy:  What you get out of it depends entirely on what you put into it.

In the UC Berkeley library, we are in fact simultaneously pursuing two approaches to METS production: a centralized approach and a dispersed approach.

The Centralized approach consists of a centralized database with associated metadata input and METS generation modules.

The dispersed approach relies largely on  Perl scripts—mostly ad hoc—to build METS objects based on existing but dispersed metadata.

We are trying to move to a Centralized approach to METS production.

We are still also sometimes using a dispersed approach for reasons I will go into in due course.

## METS creationCentralized Approach

- Components:
- GenDB:
- Relational database
- Web-based input modules
- Batch load input modules
- GenX
- Generates METS objects from GenDB.

**Notes:**
The Centralized approach to METS creation that we are attempting to achieve consists of two main components: a component we call GenDB, and a component we call GenX.

## METS creation GenDB Functionality

- Metadata gathering tool
- Facilitates input of structural & descriptive md (manual & batch)
- Processing control tool
- Guides the digitization process by vendors (image, transcription/structured text content)
- Imports content file names and associated technical metadata coming out of digitization process

**Notes:**
The GenDB database and its associated modules actually function not just as a metadata gathering tool but also as a processing control tool.  

As a metadata gathering tool it:

## GenDB:

- Typical Flow

- GenDB
- User

- SQL Server
- Database

- Imaging/
- Transcription
- WorkOrders

- Vendor

- Technical MD
- Spreadsheets

- METS

**Notes:**
I think that this diagram will help clarify GenDB’s functionality and the typical work flow of our digitization projects.. 

Using the GenDB web interface, keyers at the repositories participating in a digitization project are able to input the key metadata—largely structural and descriptive—pertaining to the materials that are to be digitized.  This structural and descriptive metadata is saved to the centralized database.  

As soon as the structural metadata and a minimal amount of descriptive metadata has been completed the keyer can generate a digitization work order that tells the digitization vendor how the material is to be digitized and how the content files coming out of the digitization process should be named.  These work orders are sent, along with the material to be digitized, to the digitization vendor.

The digitization vendor produces the digital content files along with spreadsheets containing the content file names and associated technical metadata.  A database module  imports the information from the technical metadata spreadsheets and the metadata gathering process is complete.  The GenX module can now produce the golden METS objects. 

Golden Egg joke

## METS creation: Centralized GenDB Database

- SQL Server database (Relational database)
- Structural, descriptive and admin md recorded in flat table structure:
- GenDB element sets antedate METS, MODS, etc.
- MOA2.DTD determined structural metadata.
- Multiple standards influenced descriptive md element set.
- Accommodated to MODS
- MOA2.DTD determined image technical md element set
- Accommodated to MIX

**Notes:**
I won’t go into great technical detail about GenDB.  For those of you lucky enough to have tickets, my colleague Giulia Hill will reveal some of its nuts and bolts at the METS Generation break-out session tomorrow. I will, however, make some brief general technical comments about each of its components.

The GenDB database itself is a relational database, specifically a SQL Server database.

Since it is not an XML database, the data can’t literally be stored in METS format—but just a METS compatible format. In fact the structural metadata, descriptive and administrative metadata are stored in a flat table structure, on which a hierarchical structure is somewhat artificially imposed through a system of internal links.

While now METS compatible,  GenDB element sets by and large antedate METS and its available extension schemas.

The MOA2.DTD determined GenDBs structural metadata, and we have been able to carry this forward without any adjustments to METS applications.

## METS creation: Centralized GenDB Web UI

- Web based interface for manual input
- Java Servlet Driven
- Java Server Backend
- Key Features
- Configurable (by Project Managers)
- Shields users from the complexities of METS and standards-specific vocabularies

## METS creation: Centralized GenDB Batch Interface

- Components:
- Batchload schema to which MD to be loaded must conform.
- Batch processor (Java module)
- Other components shared with Web Interface
- When useful
- Anytime input can be programmatically generated from existing sources

**Notes:**
As I mentioned, in addition to its web interface for manual input, GenDB also has a batch interface for the batch input of metadata.

## METS creation: Centralized GenX: Generating METS

- Components:
- Java Program with graphical UI
- Key Features
- Shows list of Objects available for export
- On demand, queries database to gather md pertaining to selected object(s) and package as METS with MODS, MIX extensions

**Notes:**
The final component of our Centralized approach to generating METS objects is GenX, which is the METS generation component itself.

## METS creation: Centralized Reality Check

- Main GenDB limitations
- Better at physical than logical structuring
- No support yet for video/audio content
- Redundant Keying of DescMD
- No Collection level input

**Notes:**
While goal is to achieve a centralized approach, GenDB still has a number of limitations.

Because it is a processing control tool, and processing is done at the physical structure level, structural metadata for objects in the GenDB database must ultimately reflect the physical structure of the materials.  This can be problematic when there is a conflict between physical and logical structure, and the physical structures cross logical boundaries.  There is probably no cure for this as long as GenDB needs to function as a processing control tool.

GenDB has no support yet for audio/video content

Descriptive metadata for items being digitized is often available in our online catalog; but we have no provision yet for capturing this automatically from the GLADIS catalog.  So insofar as we want the descriptive md to be embedded in our METS objects (which we do for ease of collection searching purposes) , staff must recreate it in GenDB input process.

Finally, and probably biggest deficiency from our users standpoint, is the lack of support for collection level input.  Our users want to be able to work from the collection level down through the item level; and to be able to generate EADs as well as METS objects using the GenDB database.

Work is in progress to remedy all but the first of these deficiencies.

## METS CreationDispersed Approach

- When used
- Any time requisite metadata  and content files already available—just needs to be harvested and packaged
- Legacy databases
- Projects not requiring GenDB to control digitization process
- Method: Add hoc PERL scripts gather md & package as METS.
- Why used:
- Expedient. Lots of PERL programming expertise.

**Notes:**
While we are moving towards a centralized approach to metadata gathering and METS creation, we do find ourselves sometimes using ad hoc, dispersed approaches to METS production.  This might happen with the requisite content files and associated metadata already exist and just need to be harvested and packaged. So we have used this method with legacy (pre-METS) databases such as Chinese in California; or where the digitization work is being done by the owning repository itself, rather than an external vendor, as is the case with our “Stored Materials table of Contents” project. 

The method of the dispersed approach is simply to write ad hoc PERL scripts to gather the metadata and content file information and package it up as METS. 

We use this method of METS production mainly as a matter of expedience; it makes good use of available PERL programming expertise.

## Stored Materials Project Flow

- MARCtoMODS

- GLADIS
- Catalog

- Perl Script 1

- MARC
- Records

- MODS
- Records

- JPEG
- TOC scans

-  Perl Script 2

- METS
- Objects

- 1

- 2

- 3

- 4

- 5

- 5

- 6

**Notes:**
The METS production flow for our Stored Materials Table of Contents project will give you a good idea of how we are applying this approach. 

Unlike most projects that are under GenDB’s control, the Stored Materials project work flow begins with digitization:  Staff at the storage facility scan and ocr the table of contents of books in storage and place the scans in a holding directory of the project host machine.  

After a certain number of scans have been completed a PERL script reviews the recent scan filenames and requests  MARC versions of the GLADIS catalog records corresponding to the scans. A GLADIS program then simultaneously prepares the MARC output, and inserts 856 links in the GLADIS records that point to the “soon to be available” METS object representing the table of contents. 

The MARC output records are then run through the  reliable MARC to MODS routines  available from the Library of Congress to produce MODS versions of the MARC output.  

Once the MODS output is ready, a second Perl script combines the MODS descriptive metadata with the image and ocr content file information to produce METS objects representing the Tables of Contents.

## METS CreationFuture Trends

- Trend toward centralization will continue; replace dispersed approach
- Batch interface can handle most “dispersed” situations
- Makes future maintenance easy
- Helps insure consistency in METS output

**Notes:**
As useful as the dispersed approach sometimes is, I expect that the trend towards centralization will continue.  For one thing, the batch interface to GenDB can now handle most of situations for which we are currently using the dispersed approach.  Our PERL geeks needed despair, however, as ad hoc PERL scripts will still have a part to play in the batch load process; they will be needed to create the source batch load files for loading the metadata into GenDB.

With the metadata loaded into the GenDB database, future maintenance becomes easier.  And funneling everything through one METS creation program—GenX—will help insure the consistency of METS objects.

## METS CreationCommon Issues

- Immaturity/Lack of Extension schemas
- Problems for expressing MD
- Problems for gathering MD
- METS & related schema status
- METS stable
- Descriptive Metadata: MODS, DC Simple, MARCXML
- Technical MD: still immature, if available at all

**Notes:**
Regardless of the approach a METS implementor might use to gather the requisite metadata and generate METS objects, they all face a common problem when it comes to expressing this metadata: the immaturity or lack of appropriate extension schemas for expressing some of these metadata. 

Ultimately this becomes a problem for gathering metadata as well.  Even though the main GenDB element sets were defined in advance of METS, MODS and MIX, we have had to make numerous adjustments to this element set as we have settled on target schemas we want to use in the context of METS. 

METS itself is stable; most recent changes have been backwards compatible.
Several mature schemas exist for descriptive metadata.  We have chosen MODS, and were fortunate to be able to participate in its development which helped insure that it would meet our needs.  MODS has also proved to be very flexible.  However, while MODS is fairly mature, it has at least until recently tended to change somewhat frequently in non-backwards compatible ways, which has caused some problems for us.

Technical MD schemas tend to be less mature where they are available at all.  Jerry McDonough has been valiantly working to fill some of the gaps; but practically speaking as METS implementors we are faced with the prospect of having to do the best we can with what’s available now; and possibly with transforming or replacing the technical metadata in our METS objects later.

## METS Access

- Main sub-themes
- Discovery
- Presentation of content & associated metadata

**Notes:**
The second common METS theme is providing access to METS object.  Here there are two main sub-themes:  Discovery and Presentation.

## METS Access: DiscoverySearch Support at UCB

- No centralized search support for our METS/MOA2  repository
- Current discovery mechanisms:
- Online catalog links
- Finding Aids, OAC supported searching
- Project home pages and Finding Tools

## METS Access: DiscoveryProjected Support 

- Options considered:
- Tamino/XML database
- Abandoned
- Too many limits on XML support
- Still have to build search interface from scratch
- Cheshire
- Greenstone

**Notes:**
We do want and intend to provide consistent support for searching within individual project repositories as well as  across project repositories.

To this end we have explored three main possible options:  Tamino (or other XML database), Cheshire, Greenstone

Under the Tamino option we thought that we would load our METS objects into a native XML database and use its indexing and XMLQuery based search support to provide the basis for our METS repository search needs.

The Cheshire and Greenstone options look more promising.

## METS Access: DiscoveryCheshire Option 

- What is it:
- Developed by Ray Larson at U.C. Berkeley
- “next-generation online catalog and full-text information retrieval system using advanced IR techniques”
- Advantages:
- Free
- Indexes “hub documents” (like METS) and content files where they reside
- Very sophisticated searching/ranking algorithms including Boolean
- OAI interface

**Notes:**
I hasten to point out that what I have to say about Cheshire and Greenstone should be taken with a grain of salt.  Not only are our explorations incomplete; but new versions of both “products” are in the works, and these promise to have substantial advancements over the current versions.  

## METS Access: DiscoveryCheshire Option (2)

- Disadvantages:
- Does not support Unicode yet
- coming in version 3
- Limited collection management support:
- Adding collections
- Developing search interface
- No object-level presentation support

## METS Access: DiscoveryGreenstone Option

- What is it:
- Developed by New Zealand Digital Library Project at University of Waikato
- “suite of software for building and distributing digital library collections. It provides a new way of organizing information and publishing it on the Internet or on CD-ROM.”
- Advantages
- Free/Open Source
- Next version will be METS-based
- Strong collection management support

## METS Access: DiscoveryGreenstone Option (2)

- Advantages (cont’d)
- Unicode support now
- Fairly sophisticated search support
- Some presentation support
- OAI support in progress
- Disadvantages
- Does not index objects where they reside
- This limitation may apply to METS-based version as well

**Notes:**
Our Digital Publishing Group currently evaluating Cheshire and Greenstone, and will be reaching decision shortly
Problem: Both have new versions in progress that might seriously impact decisions

## METS Access: PresentationGenView

- Java-based Software suite developed at UCB for MOA2/METS presentation
- History
- Originates in Making of America II (1997)
- XSLT in infancy
- Web Services non-existent
- CORBA/RMI and servlet technology were “hot”
- GenView originally supported MOA2 objects
- GenView adapted to accommodate METS

**Notes:**
We have gone a lot further with the presentation of METS objects than we have with search support.  Our METS presentation tool is a 

## GenView: Basic Architecture

- Web
- Interface

- METS Java
- Objects

- Java Servlet

- Repository Manager (java)

- METS Java
- Object

- RMI

- METS XML
- Documents

- XSLT

**Notes:**
This slide summarizes the components and strategy of the GenView approach to METS presentation.

A key feature of the GenView strategy is that we preparse the METS XML Documents, and create and save Java analogs for these METS source documents.   The METS metadata is arranged in the Java objects in a way that expedites navigation. For the most part GenView components interract with the Java version of the METS object to fulfill the  users navigation and display requests.  

While GenView does not primarily use an XSLT approach to presentation, it does in fact use it to display descriptive metadata on demand. 

## METS Access: PresentationGenView Evaluated

- Advantages:
- It exists...
- Presentation very efficient
- Meets basic presentation needs well
- Disadvantages
- Geared towards image/native browser content
- Limited configuration options
- Complex; difficult to maintain

**Notes:**
My colleague Garey Mills is currently giving GenView presentation a facelift.  (Also he’s undoing so many of the things I have done that I ought not to have done....)

Planned evaluation some months hence:  continue along current path or replace. If we do replace it, my guess is that we will go with an xslt approach such as those that have been developed by:

## METS Access: PresentationGenView In Context

- XSLT-based approaches to METS presentation:
- NYU: Native METS
- Library of Congress: Transformed METS
- University of Chicago:
- Prebuilding html pages as part of an xslt transformation to load METS objects into Greenstone.

## Sharing METS Objects

- Sharing METS objects between METS repositories
- Plea for Profiles
- Sharing METS objects across standards
- METS and Learning objects standards

**Notes:**
The third and final METS implementation theme I want to cover today is Sharing METS objects.  I want to look briefly both at Sharing METS objects between METS repositories and Sharing METS objects across standards and communities.

## METS Sharing: METS to METSMETS as Transfer Syntax

- METS, like MARC, can function as transfer syntax
- Problem: METS offers much more leeway to implementation than MARC
- Key areas of variations:
- Structure of <fileSec> and <structMap> and relations between the two
- Extension Schemas used & required elements
- Attribute vocabularies
- mets/@TYPE
- fileGrp/@USE , file/@USE

**Notes:**
METS has been intended from the start to function as a transfer syntax: means for sharing digital objects between institutions. In this respect it could serve the same function for Library Digital Objects like MARC. Problem: offers much more leeway in its implementation than MARC does.

I have looked at the METS objects coming out of several institutions, and have been surprised at the variety of encoding practices.  Some of the key areas in which I have seen variations which may be problematic for us insofar as we want to share METS objects are:

The potential for variations creates a strong need for profiles if there is to be any hope for sharing.  Institutions that need or want to share METS objects will need formalized specifications for the structure and content of METS objects intended for certain purposes.

## METS Sharing: METS to METSSharing in UC System

- Not a theoretical goal but a reality
- All UC campus libraries participate in OAC/CDL
- Moving towards profiles:
- Common starting point: MOA2
- Working groups under auspices of OAC
- Desired Result: Submission Profiles

**Notes:**
For Libraries in the UC system, sharing METS objects isn’t a theoretical goal but a reality.  All UC Campus libraries participate in and contribute digital objects to the Online Archive of California; and the agreed on transfer syntax in METS.  However, because of the flexibility in the application of METS, in order for this to work we are going to need to establish some parameters on the ways that the OAC participants implement  METS.

In this respect we are fortunate, because we are all coming to METS from MOA2, which was CDL’s Digital Object Standard prior to the emergence of METS.  From MOA2 we are bringing to METS some shared understanding of how our METS Objects need to be structured and the metadata they need to include.

OAC has attempted to further this understanding through committees, such as the Digital Object Sub-Committee on which I have been serving, charged with laying the groundwork for achieving a METS object standard for OAC participants.

I know OAC is currently working hard to produce and document METS standards for its participants.  Hopefully out of this work will come at least some submission profiles that will insure compatibility between the METS objects coming out of Libraries in the UC System. If these profiles can look beyond compatibility within the UC System, all the better.

## METS Sharing: Across StandardsMETS and other standards

- METS originates in library world
- especially suited to library needs
- Focus/ primary concerns of other communities somewhat different:
- developing their own digital object standards
- Does this matter and why?

**Notes:**
I would like to close my talk today by looking at METS in a still broader context.

Obviously my question “Does this matter and why” is rhetorical...

## METS Sharing: Across StandardsMETS and IMS-CP

- IMS Global Learning Consortium developing learning object standards:
- IMS-CP: analogous to METS
- Goal: enable production of learning objects that can be played in IMS standards-savvy tools
- Importance of compatibility with METS:
- Incorporating library resources (METS) into learning objects
- Archiving learning objects in METS-based repositories

**Notes:**
Good case of where it matters is in the relationship between the METS community and learning technology community.

The core learning object standard that is emerging from IMS is IMS-CP, or IMS Content Packaging.  As a xml-schema based digital object standard, this standard is fairly analogous to METS.

The main goal is to enable the production of learning objects that can be played in IMS standards-savvy tools.

Compatibility and shared understanding important:  
Learning technology community wants to tap library resources (in the form of METS objects) and incorporate these into learning objects.
Libraries are finding themselves in the position of having to archive learning objects.

## METS Sharing: Across StandardsUCB Library Efforts

- METS/IMS-CP Cross Walk project
- Headed by Raymond Yee of Interactive University at UCB
- Results of effort thus far:
- Analysis of key similarities and differences between two schemas
- Preliminary x-walk
- Published in Library Hi-Tech

**Notes:**
Over the past year UCB Library has been engaged (in the person of yours truly) in a METS to IMS-CP cross walk project.  

## METS Sharing: Across StandardsUCB Library Efforts (2)

- Summary of analysis:
- Two schemas share many high level similarities:
- Hierarchical “structMap”
- “fileSec” for inventorying resources; referenced from “structMap”
- Accommodation for MD defined by other schemas
- Key difference: IMS-CP does not distinguish between presentation and content
- Future:
- Standards Merge?
- Some provision for sharing across communities

## Links

- California Heritage Collection. _[http://sunsite.berkeley.edu/CalHeritage/](http://sunsite.berkeley.edu/CalHeritage/)_
- MOA2 Project. _[http://sunsite.berkeley.edu/moa2/](http://sunsite.berkeley.edu/moa2/)_
- GenDB Web Interface Demo. _[http://sunsite2.berkeley.edu/GenDB](http://sunsite2.berkeley.edu/GenDB)_ (Account: demoman; Password: demoman)

## Links

- MODS. _[http://www.loc.gov/](http://www.loc.gov/mods)__[mods](http://www.loc.gov/mods)_
- MIX. _[http://www.loc.gov/](http://www.loc.gov/mix/)__[mix](http://www.loc.gov/mix/)_
- Cheshire II. _[http://cheshire.lib.berkeley.edu/](http://cheshire.lib.berkeley.edu/)_
- Greenstone
- 	_[http](http://www.greenstone.org/cgi-bin/library)__[://www.greenstone.org/cgi-bin/](http://www.greenstone.org/cgi-bin/library)__[library](http://www.greenstone.org/cgi-bin/library)_

## Links

- GenView demo. _[http://metsviewer.lib.berkeley.edu/metstest/BreenMETS.](http://metsviewer.lib.berkeley.edu/metstest/BreenMETS.xml)__[xml](http://metsviewer.lib.berkeley.edu/metstest/BreenMETS.xml)_
- NYU METS Page-Turner. _[http://dlib.nyu.edu/metstools/](http://dlib.nyu.edu/metstools/)_
- U. Chicago Chopin Early Editions  (Greenstone-based collection). _[http://chopin.lib.uchicago.edu/](http://chopin.lib.uchicago.edu/)_

## Links

- IMS-CP. _[http://www.imsglobal.org/content/packaging/index.cfm](http://www.imsglobal.org/content/packaging/index.cfm)_
- METS/Educational Technology Interoperability: _[http://iu.berkeley.edu/crosswalk](http://iu.berkeley.edu/crosswalk/)__[/](http://iu.berkeley.edu/crosswalk/)_