# Presentation: 215452

## IMPLEMENTATION ISSUES

## How PREMIS can be used

- For systems in development
- as a basis for metadata definition
- For existing repositories
- as a checklist for evaluation
-     “It seems that often people say they aren't ready to implement PREMIS yet, but they don't seem to realise they are already collecting some of the same information that PREMIS describes. The metadata is the same because it is often common sense that it is needed in a repository system. PREMIS can be useful to point out a few extra areas they perhaps hadn't thought of yet.”   Deborah Woodyard-Robinson

## Implementation issues: models

- Reconciling data models
- PREMIS data model is for convenience of aggregation
- Many arbitrary decisions, e.g. is an anomaly discovered during validation a property of the object or an outcome of the validation event?
- Other data models equally valid, e.g. NLNZ has Process, Object, File, Metadata
- However: PREMIS encourages consistent application of preservation metadata across different categories of objects (representation, file, bitstream)
- Implementation in relational databases
- PREMIS data model is not entity-relationship model

## Implementation issues: obtaining values

- How to create or obtain metadata values?
- Most can be populated by program but tools would help
- JHOVE, NLNZ Metadata Extraction Tool
- Tool page is available: http://www.loc.gov/standards/premis/tools.html
- Need registries for format and environment information
- Pronom, GDFR
- What values to use for controlled vocabularies?
- In version 1, PREMIS has not had a semantic unit to indicate what controlled vocabulary is used
- Version 2 introduces a mechanism to document controlled vocabularies (implementation coming)
- LC will set up registries with starter lists (taken from “suggested values”)

## Controlled vocabularies databases

- Library of Congress is establishing databases with controlled vocabulary values for standards that it maintains
- Controlled lists are represented using SKOS as well as alternative syntaxes
- Lists currently in progress:
- ISO 639-2 and MARC language code list
- MARC geographic area codes
- MARC country code list
- MARC relators
- PREMIS controlled value lists
- Thesaurus of Graphic Material
- Other possibilities
- Enumerated values in MODS schema
- Coded and uncoded value lists in MARC

## Controlled vocabularies in SKOS: example

**<rdf:Description**** rdf:about= ****"http://www.loc.gov/standards/registry/vocabulary/preservationEvents/****creation****"****>**
**<rdf:type**** rdf:resource= ****"http://www.w3.org/2008/05/skos#Concept"****/>**
**<skos:prefLabel**** xml:lang=****"en-latn"****> creation****</skos:prefLabel>**
**<skos:narrower**** rdf:resource= ****"http://www.loc.gov/standards/registry/vocabulary/preservationEvents/****migration****"****/>**
**<skos:narrower**** rdf:resource= ****"http://www.loc.gov/standards/registry/vocabulary/preservationEvents/****normalization****"****/>**
**<skos:definition**** xml:lang= ****"en-latn"****>the act of creating a new object****</skos:definition>**
**<skos:inScheme**** rdf:resource= ****"http://www.loc.gov/standards/registry/vocabulary /preservationEvents"****/>**
**</rdf:Description>**

**Notes:**
This example is from a concept scheme called “preservation events”. The controlled value described is “creation”, which is in the PREMIS data dictionary as a suggested value under eventType. It is a broader term for 2 others on the value list: migration and normalization. 

## Using controlled vocabularies in PREMIS

- Semantic units that specify a controlled vocabulary will become a “concept scheme” in LC’s registry
- Each value (now in the PREMIS DD as “suggested values”) will be expressed as a SKOS instance in LC’s concept database
- Other implementers will be encouraged to add their values within a concept scheme
- There will be a mechanism to import the values into the PREMIS XML schema to enable validation if desired
- If a concept is available in multiple standards, they may be established for broad usage in a concept scheme
- LC is exploring an RDF version of PREMIS for semantic web applications
- Those wishing to experiment: _[http://www.loc.gov:8081/standards/registry/lists.html](http://www.loc.gov:8081/standards/registry/lists.html)_

**Notes:**
Note that this is a work in progress.

## Implementation issues: conformance

- Conformance is defined in PREMIS Final Report
- if you use the name, use the definition
- local metadata can supplement but not modify PREMIS
- can define more stringent repeatability and obligation but not more liberal
- Meaning of mandatory:
- you have to know it, and you have to be able to supply it if exporting for exchange
- you don’t have to record it in repository

## Implementation issues: need for additional metadata

- preservation metadata not considered core
- core = all objects, all preservation strategies
- example of non-core = installation requirements
- more detailed information on Agents
- metadata describing Intellectual Entity
- business rules of the repository
- information about the metadata itself (e.g., who obtained or recorded a value, when last changed...)

## XML issues

## A Brief Introduction to XML

## XML Example: Data + Meaning = Information?

- <software>
**   ** <swName>**Windows**</swName>
** **   <swVersion>
- 		**2000**
**    **</swVersion>
** **   <swType>**Operating System**</swType>
- </software>

**Element**

**start-tag**

**end-tag**

**Element**

**Markup**

## XML: Extensible Markup Language

- A technical approach to convey meaning with data
- Not a natural language, although uses natural languages
- <姓名>Louis Armstrong</姓名>
- <name>Louis Armstrong</name>
- Not a programming language
- Language in the sense of:
- A limited set of tags defines the vocabularies that can be used to markup data
- The set of tags and their relationships need to be explicitly defined (e.g., in XML schema)
- We can build software that uses XML as input and process them in a meaningful way
- You can define your own markups and schemas

## XML Schema Defines:

- What elements may be used?
- Of which types?
- Any attributes?
- In which order?
- Optional or compulsory?
- Repeatable?
- Subelements?
- Logic?
- ...

## XML Validation

- XML Instance

- XML Schema

- Validator

- Valid

- Invalid

- PREMIS Publishes official schemas for validating the XML implementations.

## XML Schema Examples

- <xs:element name="software" minOccurs="0" maxOccurs="unbounded">
- 	<xs:complexType>
- 		<xs:sequence>
- 			<xs:element name="swName" minOccurs="1" maxOccurs="1" type="xs:string"></xs:element>
- 			<xs:element name="swVersion" minOccurs="0" maxOccurs="1" type="xs:string"></xs:element>
- 			<xs:element name="swType" minOccurs="1" maxOccurs="1" type="xs:string"></xs:element>
- 			<xs:element name="swOtherInformation" minOccurs="0" maxOccurs="unbounded" type="xs:string"> </xs:element>
- 			<xs:element name="swDependency" minOccurs="0" maxOccurs="unbounded" type="xs:string"> </xs:element>
- 		</xs:sequence>
- 	</xs:complexType>
- </xs:element>

## Will the following XML validate?

<software>
    <swName>Windows</swName> 
    <swVersion>2000</swVersion> 
    <swType>Operating System</swType> 
</software>

How about this?

<swVersion>2000</swVersion>

- <software>
**   ** <swName>**Windows**</swName>
** **   <swVersion>**2000**</swVersion>
** **   <swType>**Operating System**</swType>
- </software>
**How about this?**
- <swVersion>**2000**</swVersion>

## PREMIS XML schemas

- In version 1, PREMIS in XML was implemented as 5 schema for each PREMIS entity in data model and a container schema
- Allowed user to choose which parts of PREMIS to use
- Version 2 consists of one schema with each PREMIS entity defined globally so that not all need to be used
- There is an optional PREMIS container if it is desirable to keep some or all PREMIS metadata together
- Semantic units in PREMIS schemas
- XML is faithful to data dictionary
- Semantic units for objects may be validated according to the level for which they are applicable (i.e. representation, file, bitstream)
- _[http://www.loc.gov/standards/premis/premis.xsd](http://www.loc.gov/standards/premis/premis.xsd)_

## Significant changes in XML schema v 2.0

- An abstract object type allows for better validation of object category; objectCategory is not an element
- Defining main elements globally allow for reuse
- Extensibility mechanism is provided for further structure or for schemas from other namespaces
- significantProperties
- objectCharacteristics
- creatingApplication
- environment
- signatureInformation
- eventOutcomeDetail
- Rights
- Includes definitions for types of date expressions not in W3CDTF, including ISO 8601 basic format (without hyphens) and conventions for special types of dates (e.g. open-ended or questionable dates)

**Notes:**
The “Extended Date/Time Format” will be defined as a separate external schema in the future for reuse by other XML schemas.

## Implementing PREMIS using XML in METS

## METS introduction

- METS records the (possibly hierarchical) structure of digital objects, the names and locations of the files that comprise those objects, and the associated metadata
- A METS document may be a unit of storage (e.g. OAIS AIP) or a transmission format (e.g. OAIS SIP or DIP)
- METS is extensible and modular
- METS uses extension “wrappers” or “sockets” where elements from other schemas can be plugged in
- METS uses the XML Schema facility for combining vocabularies from different Namespaces
- The METS Editorial Board has endorsed PREMIS as an extension schema
- Many institutions trying to use PREMIS within the METS context

## The structure of a METS file

## Inserting technical metadata in a METS Document

**<mets>**
**  ****<amdSec>**
**    ****<techMD>**
**      ****<mdWrap>**
**        ****<xmlData>**
**	****  ****<!--    insert data from different namespace here  -->**** **
**        ****</xmlData>**
**      ****</mdWrap>**
**    ****</techMD>**
**  ****</amdSec>**
**  ****<fileSec /> **
**  ****<structMap /> **
**</mets>**

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

## METS extension schemas

- “wrappers” or “sockets” where elements from other schemas can be plugged in
- Provides extensibility
- Uses the XML Schema facility for combining vocabularies from different Namespaces
- Endorsed extension schemas:
- Descriptive: MODS, DC, MARCXML
- Technical metadata: MIX (image); textMD (text)
- Preservation related: PREMIS

## Issues in using PREMIS with METS

- Which METS sections to use and how many
- Whether to record elements redundantly in PREMIS that are defined explicitly in the METS schema
- How to record elements that are also part of a format specific technical metadata schema (e.g. MIX)
- Recording structural relationships
- How to deal with locally controlled vocabularies
- Whether to use the PREMIS container

## PREMIS and METS sections

- Flexibility of METS requires implementation decisions
- You can’t put all PREMIS metadata directly under amdSec
- What sections to use for PREMIS metadata?
- Alternative 1
- Object in techMD
- Event in digiProvMD
- Rights in rightsMD
- Agent with event or rights
- Alternative 2
- Everything in digiProvMD
- Alternative 3
- Everything in techMD
- How many administrative MD sections to use?

## PREMIS and METS sections

- Flexibility of METS requires implementation decisions:
- How many administrative MD sections to use?
- Use premis container or separate packages?
- Where to store structural relationships?
- Redundancies between PREMIS and METS?
**Experimentation will result in best practices – guidelines might help**

## PREMIS and METS sections

**Guidelines: number of sections**
- Use one amdSec with repeating subelements (techMD, etc.) **OR** repeating amdSec for each subelement – this is semantically equivalent if the appropriate sections are referenced correctly
- Agent in conjunction with an event or right should be stored in its own digiProvMD or rightsMD section to avoid redundancy (assuming that the same agent is used for different objects).
- Technical metadata from different schemas should be stored in separate techMD sections or can be embedded into PREMIS’ objectCharacteristicsExtension.

## PREMIS and METS sections

**Guidelines: PREMIS in METS sections**
- Object under techMD or digiProvMD
- Files/bitstream: techMD
- Representation: digiProvMD
- Event in digiProvMD
- Rights in rightsMD
- Agent in digiProvMD or rightsMD (depending if attached to event or rights)
**Local decisions may vary depending on processing model**

## PREMIS and METS sections

**Guidelines: PREMIS container?**
- If an implementation want to keep all PREMIS metadata together the PREMIS container is used.
- In this case the PREMIS package must go into digiProvMD

## PREMIS and METS sections

**Guidelines: structural relationships?**
- Hierarchical relationships: <mets:div> elements should be used (richer than PREMIS semantic units).
- Implementers are encouraged to store the PREMIS relationship elements in the Object schema redundantly, if the scope of exchanging objects is preservation
- Other, derivative types of relationships should always be stored in PREMIS relationship

## PREMIS and METS sections

**Guidelines: ID/IDREF referencing?**
- PREMIS and METS are using ID/IDREF to link elements:
- METS: <amdSec ID=“”/>  <div AMDID=“”/> etc
- PREMIS: linkingEventIdentifier, LinkEventXmlID etc
- METS’ IDREF attributes must not link to PREMIS elements
- PREMIS linking-attributes must not link to METS elements
**ID/IDREF links are only valid within the same schema**

## PREMIS and METS sections

**Guidelines: ID/IDREF referencing?**
- If it is intended to use the PREMIS outside of the METS container, redundant linking is necessary as METS ID/IDREF mechanism might break
- Links from METS to PREMIS sections should be made on the highest level possible – usualy pointing to the first level subelement under amdSec (digiProvMD, techMD etc.)

## PREMIS and METS sections

**Guidelines: redundant information?**
- SIZE
- CHECKSUM
- FORMAT

## <fileSec><fileGrp>
<file ID="FID1" SIZE="184302" ADMID="TMD1PREMIS TMD1MIX DP1EVENT DP1AGENT“ CHECKSUM="4638bc65c5b9715557d09ad373eefd147382ecbf" CHECKSUMTYPE="SHA-1">
<FLocat LOCTYPE="OTHER" xlink:href="BXF22.JPG" />
</file></fileGrp></fileSec>
<techMD ID="TMD1PREMIS">
  <mdWrap MDTYPE="PREMIS">
    <xmlData> <premis:object >    <premis:objectCharacteristics>      <premis:fixity>        <premis:messageDigestAlgorithm>SHA-1 </premis:messageDigestAlgorithm>        <premis:messageDigest>4638bc65c5b9715557d09ad373eefd147382ecbf  
              </premis:messageDigest>                                  	<premis:messageDigestOriginator>EchoDep</premis:messageDigestOriginator>      </premis:fixity>      <premis:size>184302</size> </premis:objectCharacteristics>

Elements defined in both METS and PREMIS:
METS: Checksum, Checksumtype
attribute of <file>
not repeatable
PREMIS: fixity
also includes messageDigestOriginator
allows multiples

**<file ID="FID1" SIZE="184302" ADMID="TMD1PREMIS TMD1MIX DP1EVENT DP1AGENT“ CHECKSUM="4638bc65c5b9715557d09ad373eefd147382ecbf" CHECKSUMTYPE="SHA-1">**
**<FLocat LOCTYPE="OTHER" xlink:href="BXF22.JPG" />**
**</file></fileGrp></fileSec>**
**<techMD ID="TMD1PREMIS">**
**  ****<mdWrap MDTYPE="PREMIS">**
**    ****<xmlData>**** ****<premis:object >****    <premis:objectCharacteristics>****      <premis:fixity>****        <premis:messageDigestAlgorithm>SHA-1 </premis:messageDigestAlgorithm>****        <premis:messageDigest>4638bc65c5b9715557d09ad373eefd147382ecbf  **
**              ****</premis:messageDigest>                                  ****	****<premis:messageDigestOriginator>EchoDep</premis:messageDigestOriginator>****      </premis:fixity>****      <premis:size>184302</size> </premis:objectCharacteristics>**
**Elements defined in both METS and PREMIS:**
**METS: Checksum, Checksumtype**
- attribute of <file>
- not repeatable
**PREMIS: fixity**
- also includes messageDigestOriginator
- allows multiples

## <fileSec><fileGrp>
<file ID="FID1" ADMID="TMD1PREMIS DP1EVENT DP1AGENT“ MIMETYPE="image/jpeg" 
<FLocat LOCTYPE="OTHER" xlink:href="BXF22.JPG"/>
</file></fileGrp></fileSec>

<techMD ID="TMD1PREMIS“
  <mdWrap MDTYPE="PREMIS">
    <xmlData>
      <premis:object>
         <premis:objectCharacteristics>
             <premis:format>
               <formatDesignation>
                 <premis:formatName>image/jpeg</premis:formatName>
                 <premis:formatVersion>1.02 </premis:formatVersion>
               </premis:formatDesignation></premis:format>
         </premis:objectCharacteristics>
Elements defined both in METS and PREMIS:
METS: MIMETYPE
attribute of <file>
optional
PREMIS: <format> 
more granular; includes name and version (although name may be MIMETYPE)
mandatory

**<file ID="FID1" ADMID="TMD1PREMIS DP1EVENT DP1AGENT“ MIMETYPE="image/jpeg" **
**<FLocat LOCTYPE="OTHER" xlink:href="BXF22.JPG"/>**
**</file></fileGrp></fileSec>**
**<techMD ID="TMD1PREMIS“**
**  ****<mdWrap MDTYPE="PREMIS">**
**    ****<xmlData>**
**      ****<premis:object>**
**         ****<premis:objectCharacteristics>**
**             ****<premis:format>**
**               ****<formatDesignation>**
**                 ****<premis:formatName>image/jpeg</premis:formatName>**
**                 ****<premis:formatVersion>1.02 </premis:formatVersion>**
**               ****</premis:formatDesignation></premis:format>**
**         ****</premis:objectCharacteristics>**
**Elements defined both in METS and PREMIS:**
**METS: MIMETYPE**
- attribute of <file>
- optional
**PREMIS: <format>**
- more granular; includes name and version (although name may be MIMETYPE)
- mandatory

## <fileSec> <fileGrp>
 <file ID="FID1" ADMID="TMD1PREMIS TMD1MIX DP1EVENT DP1AGENT">
<techMD ID="TMD1PREMIS">
   <linkingEventIdentifier>
     <linkingEventIdentifierType>ECHODEP Hub Event
     </linkingEventIdentifierType>
     <linkingEventIdentifierValue>echo12345</linkingEventIdentifierValue>
      </linkingEventIdentifier>
<digiprovMD ID="DP1EVENT">
    <premis:event>
       <premis:eventIdentifier>
         <premis:eventIdentifierType>ECHODEP Hub Event</premis:eventIdentifierType>
         <premis:eventIdentifierValue>echo12345 </premis:eventIdentifierValue>
        </premis:eventIdentifier>
       <premis:eventType>ingestion</premis:eventType>
       <premis:eventDateTime>2006-05-02T15:12:53 </premsi:eventDateTime>
    </premis:event>

Elements defined both in METS and PREMIS
METS ID/Idref: used to associate metadata in different sections and for different files
PREMIS identifiers: explicit linking between entity types

** ****<file ID="FID1" ADMID="TMD1PREMIS TMD1MIX DP1EVENT DP1AGENT">**
**<techMD ID="TMD1PREMIS">**
**   ****<linkingEventIdentifier>**
**     ****<linkingEventIdentifierType>ECHODEP Hub Event**
**     ****</linkingEventIdentifierType>**
**     ****<linkingEventIdentifierValue>echo12345</linkingEventIdentifierValue>**
**      ****</linkingEventIdentifier>**
**<digiprovMD ID="DP1EVENT">**
**    ****<premis:event>**
**       ****<premis:eventIdentifier>**
**         ****<premis:eventIdentifierType>ECHODEP Hub Event</premis:eventIdentifierType>**
**         ****<premis:eventIdentifierValue>echo12345 </premis:eventIdentifierValue>**
**        ****</premis:eventIdentifier>**
**       ****<premis:eventType>ingestion</premis:eventType>**
**       ****<premis:eventDateTime>2006-05-02T15:12:53 </premsi:eventDateTime>**
**    ****</premis:event>**
**Elements defined both in METS and PREMIS**
**METS ID/Idref:** used to associate metadata in different sections and for different files
**PREMIS identifiers**: explicit linking between entity types

## <structMap TYPE=“physical”>    
  <div ORDER="1" TYPE="text">
  <:fptr FILEID="FID9"/>
     <div ORDER="1" TYPE="page" LABEL=" Page [1]">
     <fptr FILEID="FID1"/></mets:div>
      <div ORDER="2" TYPE="page" LABEL=" Page [2]">
      <fptr FILEID="FID2"/></mets:div>
   </div>

<premis:relationship>
   <premis:relationshipType>structural</premis:relationshipType>
   <premis:relationshipSubType>is sibling of </premis:relationshipSubType>
  <premis:relatedObjectIdentification>
     <premis:relatedObjectIdentifierType>UCB</premis:relatedObjectIdentifierType>
     <premis:relatedObjectIdentifierValue>FID2</premis:relatedObjectIdentifierValue>
     <premis:relatedObjectSequence>1</premis:relatedObjectSequence>

Elements defined both in METS and PREMIS:
METS: structMap
details structural relationships and is the heart of the METS document
hierarchical, so may be more expressive than PREMIS semantic units
links the elements of the structure to content files and metadata
PREMIS: <relationship> 
details all kinds of relationships, including structural
data dictionary says that implementations may record by other means  

-   <div ORDER="1" TYPE="text">
-   <:fptr FILEID="FID9"/>
-      <div ORDER="1" TYPE="page" LABEL=" Page [1]">
-      <fptr FILEID="FID1"/></mets:div>
-       <div ORDER="2" TYPE="page" LABEL=" Page [2]">
-       <fptr FILEID="FID2"/></mets:div>
-    </div>
- <premis:relationship>
-    <premis:relationshipType>structural</premis:relationshipType>
-    <premis:relationshipSubType>is sibling of </premis:relationshipSubType>
-   <premis:relatedObjectIdentification>
-      <premis:relatedObjectIdentifierType>UCB</premis:relatedObjectIdentifierType>
-      <premis:relatedObjectIdentifierValue>FID2</premis:relatedObjectIdentifierValue>
-      <premis:relatedObjectSequence>1</premis:relatedObjectSequence>
**Elements defined both in METS and PREMIS:**
**METS: structMap**
- details structural relationships and is the heart of the METS document
- hierarchical, so may be more expressive than PREMIS semantic units
- links the elements of the structure to content files and metadata
**PREMIS: <relationship>**
- details all kinds of relationships, including structural
- data dictionary says that implementations may record by other means

## Should semantic units be recorded redundantly?

- Various options are possible when there is overlap between PREMIS and METS or PREMIS and other technical metadata schemas
- Record only in METS
- Record only in PREMIS
- Record in both
- Are there advantages in using PREMIS semantic units?
- Is it important to keep PREMIS metadata together as a unit? There may be an advantage for reuse and maintenance purposes

## How to record elements from 2 different technical metadata schemas

- Format specific metadata may be included in addition to PREMIS general technical metadata
- Use multiple techMD sections and specify source in MDType attribute and/or namespace declaration
- e.g. MDTYPE=“NISOIMG” or “PREMIS”
- Give MIX schema declaration in METS document
- MIX was recently revised to correspond with the revision of the Z39.87 technical metadata for digital still images standard; names harmonized with corresponding PREMIS semantic units
- For digital still images, best practice may be to use PREMIS for general semantic units defined in PREMIS and MIX for format specific units without redundancy

## Examples of PREMIS in XML

**PREMIS in METS:**
- _[Portrait of Louis Armstrong ](http://www.loc.gov/standards/premis/louis-2-0.xml)__(XML) (Library of Congress)_
- _[Web Presentation ](http://lcweb2.loc.gov/diglib/ihas/loc.natlib.gottlieb.09601/default.html)__of this object_
- _[Peoria County, Illinois aerial photograph ](http://dli.grainger.uiuc.edu/echodep/METS/METSProfile.asp?f=DRAFTS/BaseMETSProfile.xml&q=//prof:Appendix%5B@NUMBER='1'%5D/mets:mets)__(ECHO Depository, UIUC Grainger Engineering Library)_
**MATHARC implementation:**
- _[http://pigpen.lib.uchicago.edu:8888/pigpen/uploads/13/asset_descr_mets_premis_02v2.xml](http://pigpen.lib.uchicago.edu:8888/pigpen/uploads/13/asset_descr_mets_premis_02v2.xml)_
**UC examples using PREMIS**
**Stanford (geospatial and “transfer manifest”)**
**UCSD (complex object)**
**UCB (general METS profile)**

**Notes:**
Bring up the web presentation and show that there are 2 versions of the intellectual entity (the photograph) that are included in this METS file. Note that the METS description on the Web doesn’t include the PREMIS metadata. The link to Portrait of Louis Armstrong is an illustration of the use of PREMIS (v 2.0) and MIX in a METS document.

## MPEG-21 Digital Item Declaration (DID)

- ISO/IEC 21000-2: Digital Item Declaration
- A promising alternative to represent Digital Objects
- Starting to get supported by some repositories, e.g., aDORe, DSpace, Fedora
- A flexible and expressive model that easily represents compound objects (recursive “item”)
- Attach well-formed XML from persistent namespaces as metadata

## Abstract Model for MPEG-21 DID

*resource*

*resource*

*resource*

*component*

*component*

*descriptor/statement*

*descriptor/statement*

*descriptor/statement*

*descriptor/statement*

*item*

*item*

*container*

***resource***: datastream

***component***: binding of *descriptor/statements* to datastreams

***item***: represents a Digital Item aka Digital Object aka asset. *Descriptor/statement* constructs convey information about the Digital Item

***container***: grouping of *items* and descriptor/statement constructs pertaining to the container

## Mapping

*resource*

*resource*

*resource*

*object3*

*object4*

*premis: object*

*premis:object*

*premis:premis*

*DIDInfo*

*object2*

*object1*

*DID*

- All rights, events, and agents go here.
- The top level object goes here. Other objects may be duplicated here or linked here.

*premis: object*

## Partial Implementation in DID

*resource*

*resource*

*resource*

*object3*

*object4*

*premis: format*

*premis:significantProperties*

*premis:premis*

*DIDInfo*

*object2*

*object1*

*DID*

- When metadata are not sufficient to form the top level PREMIS elements, partial implementation may be done if PREMIS elements are globally defined.

*premis: creatingApplication*

## Summary: container formats

- A container format is needed to package together all forms of metadata (of which PREMIS is one) and digital content
- Use of a container is compatible with and an implementation of the OAIS information package concept
- Co-existence with other types of metadata requires best practices for both approaches; redundancy seems to be preferred
- Changes to the next version of the PREMIS XML schemas will facilitate a phased approach to full PREMIS implementation
- Development of registries for controlled vocabularies will benefit implementation
- Tools are being developed to facilitate implementation

## Summary: METS vs. MPEG 21 DIDL

- METS and MPEG DIDL are similar types of container formats in that both are expressed in XML, both represent the structure of digital objects, and both include metadata
- MPEG DIDL doesn’t have the segmentation in metadata sections that METS does, so this implementation decision need not be made in DIDL
- METS is open source and developed by open discussion, mainly cultural heritage community
- MPEG DIDL is an ISO standard and has industry support, but is often implemented in a proprietary way and standards  development is closed
- It would be possible to transform a METS container to a MPEG DIDL and vice versa; development of stylesheets will enable transformations

## Implementers’ panel

- What types of objects are you preserving?
- Has your institution implemented a preservation repository?
- What preservation metadata are you recording?
- How are you recording it, e.g. database, METS/XML, other
- Do you plan to exchange preservation metadata with other repositories?
- Are you planning to or already using PREMIS?
- Which semantic units are most useful?
- Which semantic units are least useful?
- What difficulties have you had applying PREMIS units?