MIM 2007 Germany

Notes on the METS Implementors Meeting

SUB Goettingen, 08 May 2007

Thanks to NESTOR Project and the State and University Library of Goettingen for sponsoring and arranging the second METS Implementation Meeting. 

Agenda:

• Participant reports / issues / questions
• METS Profiles, moderator: Rob Wolfe, MIT Libraries
• METSbeans - a METS API for java,  moderator: Markus Enders, SUB Goettingen
• Tools, moderator: Brian Tingle, California Digital Library

Reports were given by participants summarizing their institutions’ involvement or interest in METS and what issues or questions they would like to have addressed. 

METS Profiles

• Rob Wolfe introduced some issues related to METS Profiles that he’s experienced as MIT and DSpace have begun working with profiles:  .
• Found it needed supplementary documentation, especially for developers
• Bundles issues: grouping of files into bundles.  Uses FileGrp for this purpose.
• METS SIPS get converted into METS AIPS
• Profile used in tool Lightweight Network Interface—which ingests both METS and IMS-CP.
• Converts to AIP
• AIP has separate METS profile
• Working with University of  California at San Diego on federated archiving
• Process for developing profiles.
• Questions and concerns:
• How to incorporate PREMIS into METS.
• How METS can help achieve interoperability.  How to build federations of interest.

Issues raised by group discussion:

·       Need to test documentation on profiles on Web

·       Should there be a better mechanism for announcing the availability of new profiles on the METS list?

·       How to deal with versioning of schemas:  should METS and METS profile schema have a version element? 

·       What does machine actionability mean in terms of profiles?

• Somewhere to record what consequences of certain elements.
• <rationale>?
• Incremental move to actionability? Or all at once.
• Need to determine what can be be machine actionable.

·       Extending use of URIs to reference

·       What should be the level of detail of specs on Profile

·       How many profiles should we have – many different or a few that many use?

·       Need for hierarchy of profiles: some means of expressing relationship/derivation of profiles from other.  How best to express profiles that are more abstract in relation to those more specific?

·       When is it useful to register a profile?  Should every one be registered or only if reusable?

·       What about related profiles

·       Need better way to group profiles.

·       Controlled vocabulary for different relationship, e.g., RELATED ITEM controlled vocabulary

·       Reusability:

·       Should profiles be made more modular so people can pick and choose what’s useful?

·       Small organizations have difficulty developing their own, but how to figure out focus for generic profile?

·       Some kind of best practices profiles?

·       Focus of generic profiles:

·       those tied to specific systems: DSpace,

·       tied to tasks, specific uses, specific extension schemas (PREMIS)

·       Issue of who would develop these profiles

·       Go the way of DC: identify communities for developing profiles? Difficult with smaller METS community.  Also DC has tremendous diversity. Modularity may impact this.

·       Controlled vocabularies; expression of rule

·       METS too liberal? 

·       Goals upon which to focus for profiles: reusability, interoperability.

·       More specific information is needed to understand how METS should work with PREMIS.

METS API: Markus

From Markus presentation: 

·       Needs to support abstract data model

·       API is more framework

·       Implementation Issues

·       When schema changes needs to change without expensive programming

·       Needs to support multiple programming languages

·       Level issues: granularity issues

·       Options:

·       Apache xmlbeans/SUN JAXB

·       Modules that that bridge programming languages

·       Granularity: need element/attribute access to lowest level.

·       Markus’ attempt to build:

·       Uses xmlbeans based API for Java\

·       Creates an interface for each schema object and an implemntation to read/write this object to XML.

·       Can create DOM tree at any time—if non-schema based xml-data needs to be stored.

·       Implementation Issues:

·       Level one: METSBeans

·       allows access to single METS elemnets attributes and their relationahips

·       xmlbeans based API for java

·       Level two

·       Every type from the schema becomes obe class. Classes are generated automatically from the XML-schema

·       additional APIS can be generated and integrated for external schemas

·       complexType s become interface accompanies by an impl class.

·       Internal architecture:

·       METSDocument becomes the topmost class.  Instantiates the document. Necessary to do anything else.  Use factory class to instantiate. 

·       Numerous standard methods: get, set, add and remove methods.

·       Also methods for getting and setting attributes.

·       MdSecType:

·       Parsing md: parsing methods.

Issues raised from initial build:

·       No support for other languages: must use language bridge

·       need for additional functions: must use helper class.

·       no official implementation of helper class.  Needed functions:

·       Generating IDS

·       creating a particular kind of technical metadata

·       miscellaneous other functions

·       Users must generate their own class files—not already available.

·       How to integrate extension schema.  API needs to manage data from the other

·       Problems:

·       API depends on the quality of XML schema.  XML schema was never intended to be used as API. 

·       No type for METS header—so you don’t get a METSheader class

·       Some schemas don’t have a top level element (DC). 

·       How to continue.

·       Asks people who create METS to try out. 

·       Need documentation

·       Identify needs and implement helper class

·       Need Application Layer—profile specific.  Classes that really reflect your content model.

Issues raised from discussion:

·       Question about experiences with Dublin Core API (? -- from Carl)

·       Persistency issues: Reference implementation: Apache Jackrabbit. 

·       Ability to access just portions of the serialized xml serialization.  Need framework for xml serialization.

·       Possibility of generating classes from validatable profile schema. 

·       API for content model translate from abstract content model to METS.

·       Other methods of building METS:

·       XSLT transforms (BL)

·       DOM suite – DOM level 3. More abstract way.

·       Harvard toolkit:

·       Based JAXB

·       Advanced support not originally available in JAXB

·       Ultimate value: you can be sure of creating valid METS. 

METS Tools, Brian Tingle

Notes from Brian’s presentation on tools used at CDL: 

·       GenDB

·       Archivist Toolkit: Does EAD and METS

·       MOAC Community Toolbox.  Filemaker Pro for METS/Asset management for Museum community

·       7Train.  Built on ContentDM originally.  But extensible.  Uses 7Train profiles.

·       METS collected together into a single system.

·       Profile driver: selects appropriate extraction style sheet for the profile

·       Also provides frameworkID (?used for what?)

·       Access systems: extensible text framework (similar to Cocoon: Saxon/Lucene integration)

·       Lazy Tree: provides start and stop parts certain section—allows for efficiency in searching without parsing the entire document.

Issues raised from discussion: 

·       Transformation from legacy formats: needs for transformation.

·       DigiTool: issue about how generic—not clear.

·       ID issues

·       How best to provide support wide variety METS/XML formats?

·       New users:  planning to develop own tools or use existing?

·       Problem with existing tools:

·       Content model tends to be local—specific to particular projects/implementations. 

·       Problem with Tools page: no link to underlying data model. 

·       Even with tool that outputs to common format, still a need for assistance with transformation to specific format needed by client (e.g., CCS service).

·       Would be useful to have generic tool for automatic generation of mets based on machine actionable profile. 

·       Actions METS board can take:

·       Nancy:  Another event focusing on tools for purposes of both education and finding out what else is needed?  Could be standard questions asked of presenters in order to get answers to same questions. 

·       Markus: ask people to present what they expect/need from software tools supporting METS.  Need for use cases.

·       CCS: Need to know use cases. 

·       Tools questionnaire the responses to which would be linked to the entries on the tools page. 

·       Angela: may want use a lot of different tools that can be coordinated., Also tools for different presentations of METS to facilitate different applications. 

·       Brian: need to think more abstractly than METS? 

·       Status of tools that can deal with METS and maybe produce METS for end user:  so content can be disaggregated and reassembled for end user.

·       For tools profiles:  ask what developer sees as target user base.

·       Gilberto:  need to shield user from xml, nitty gritty technical details. 

·       Tools for profiles:

·       Generation tool that can produce instance documents from actionable profile

·       Tobias: should be possible automatically to generate Java files to create METS based on actionable profile

·       Nancy: Telcert has done for IMS-CP?  (May just be for validation?)  May be worth checking into.

·       Coming up with machine actionable profile: do incrementally?

·       Issue with extension schema and actionable profile.Use web service to provide modularity. 

·       Add behaviorSec to profile?  Or WSDL in the profile?  Need to use Schematron or WSDL.

·       Use of more specific schema that gets invoked based on profile to insure profile conformance.