BAM/PFA

Museums and the Online Archive of California (MOAC) builds on existing standards and their implementation guidelines provided by the Online Archive of California (OAC) and its parent organization, the California Digital Library (CDL). Setting project standards for MOAC consisted of interpreting existing OAC/CDL documents and adapting them to the projects specific needs, while at the same time maintaining compliance with OAC/CDL guidelines. The present overview over the MOAC technical standards references both the OAC/CDL umbrella document and the MOAC implementation / adaptation document at the beginning of each section, as well as related resources which provide more detail on project specifications.

The project implements specifications for digital image production, as well as three interlocking file exchange formats for delivering collections, digital images and their respective metadata. Encoded Archival Description (EAD) XML describes the hierarchy of a collection down to the item-level and traditionally serves for discovering both the collection and the individual items within it. For viewing multiple images associated with a single object record, MOAC utilizes Making of America 2 (MOA2) XML. MOA2 makes the images representing an item available to the viewer through a navigable table of contents; the display mimics the behavior of the analog item by e.g. allowing end-users to browse through the pages of an artist's book. Through the further extension of MOA2 with Text Encoding Initiative (TEI) Lite XML, not only does every single page of the book display in its correct order, but a transcription of its textual content also accompanies the digital images.

Both technical standards and their implementation by the OAC have undergone a number of changes since the outset of the MOAC project in 1999. For example, MOAC started out as an EAD SGML project, yet migrated to XML as soon as the OAC allowed submissions in the emerging format. As a coveted side effect, MOAC has replaced the use of character entities for special characters with UTF-8 (Unicode Transformation Format) encoding, a standard recommended for use with XML. A UTF-8 encoded XML document assigns a unique number to any of the special characters covered in the Unicode specifications (95,221 as of Unicode 3.2). The client will see the correct character displayed as long as their font contains the corresponding glyph.

An even more profound paradigm shift in terms of metadata encoding, submission and display comes in the form of the new digital object standard METS (Metadata Encoding and Transcription Standard). Although the CDL has not yet officially adopted METS, information on the most recent developments and how the new format may shape MOAC in the future can be found in the digital objects section of this document. These two instances of fairly significant changes in the project's specifications may serve as a gentle reminder that despite its solid foundation in standards, the MOAC information architecture will continue to face the challenge of an ever-changing technical environment.

CDL Digital Object Standard: Metadata, Content and Encoding (May 18, 2001) [PDF]

Daniel L. Johnston. A Simplified Standard Method of Digital Image Tonal Capture for Archival Project. PICS 2002: IS&T's PICS Conference. Portland, Oregon, 2002. p. 210-213

The MOAC project standard for digital imaging consists of two components: a baseline standard for digital still image master files and derivatives, and a standard for digital imaging metadata. The standard for digital still image masters and derivatives fully complies with the Digital Image Format Standards.

	Resolution	File Format	Color Target
Master	> 600 ppi or 3000 pixels / longest (whichever possible / yields bigger file size) OR 20 MB target	TIFF (uncompressed)	Yes
Submaster	< 3000 pixels / longest dimension; color bar cropped out	Tiff (uncompressed)	No
Access	> 150 pixels / longest dimension (recommended 640, 800 or 1024)	JPEG (compressed)	Optional (recommended No)
Thumbnail	= 150 pixels / longest dimension	JPEG (compressed)	Optional (recommended No)

All digital imaging takes place at Gamma 2.2; master files are in RGB color space (access / thumbnails may be in sRGB) at a bit depth of 24bit for color or 8 bit for b/w source materials.

The combined guideline of resolution / pixel dimension / file size for master files ensures that captures from fairly large, fairly small or oddly proportioned sources will yield an adequate amount of data. Some examples might help clarify the need for the differentiated approach: A fairly small object captured at 600 ppi yields a file which will be unsatisfactory for most uses. If the original object is the size of a slide (1.5 x 1 inch), a 600 ppi capture standard results in a file of 900 x 600 pixels or 1.5 MB of data. The same object captured at 3000 pixels per longest dimension will yield a file of 3000 x 2000 pixels or 17 MB of data. Obviously, the second capture comes much closer to fulfilling the promise of "one file, many uses" any master file has to live up to, and it comes close enough to the file size guideline of 20 MB.

On the other hand, the capture of a fairly large object illustrates a situation in which a ppi-based standard alone would demand a capture exceeding hardware capability. If our original material is the size of a handscroll (e.g. 12 x 60 inches), the 600 ppi standard would insist that we capture a file of 7200 x 36000 pixels, or 740 MB in data. However, the same object captured at our second specification of 3000 pixels per longest dimension will only yield a file of 600 x 3000 pixels or 5 MB. In this case, because of the odd proportions of the object, the appropriate target for capture would be our 3^rd guideline of approximating 20 MB per image file, yielding about 100 ppi, or about 1200 x 6000 pixels in our example. The 20 MB figure derives from the file size of a 4x5 transparency scanned at 600ppi.

For an uncompressed image at 24bit color, the following formulas may be used to determine filesize:

For institutions engaging in imaging exceeding the master file specifications significantly, we also recommend saving a submaster file. The submaster has no color bar; it has a smaller pixel dimension than the master file (between 2000 and 3000 pixels / longest dimension). This file only contains the salient visual content to be communicated, and it is smaller and more portable than the master file. It may be used to (1) create new access / thumbnail files through batch processing, (2) as the back-end file for a dynamic imaging server or (3) as a source file for most mid-end print uses.

To ensure color accuracy, the project recommends color adjustments with the help of color bars (such as a Kodak Q-13). The color bar provides a target of known values which allows for color correction either immediately after the capture, or at any later date. For more details on how to use color bars in archiving digital image files, please consult Daniel L. Johnston's article ("A Simplified Standard Method of Digital Image Tonal Capture for Archival Projects"). In keeping with OAC/CDL recommendations, most MOAC project partners chose this method for safeguarding color over automatic color management software.

Patch	0 (A)	1	2	3	4	5	6	7(M)	8	9	10	11	12	13	14	15	16(B)	17	18	19
RGB	242	218	196	177	159	143	129	116	105	94	85	77	69	62	56	50	45	41	37	33

Choosing the A, M and B point as references points for adjusting scanner settings and spot checking individual scans usually yields satisfactory results. You may adjust your scanner by using a tonal curve (or other color manipulation tools in your scanning software) on the scan of a Kodak Q-13 target to approximate the RGB values in the tables. Using those settings for subsequent scans, the colors should be within acceptable range of the target values, and may be spot-checked after each scan e.g. with the Color Sampler Tool in Photoshop. We recommend that the color bar be cropped out of access and thumbnail files to maximize screen real estate for content.

Since many institutions already had pre-existing digital images which may not have been captured in compliance with the project specifications, MOAC decided to allow those legacy resources to be submitted. These legacy image files will be re-captured by partner institutions according to project specifications at a later date.

For institutions without a file server, the OAC has offered to host digital image files by special arrangement; otherwise MOAC endorses a de-centralized model in which each institution hosts their own images locally.

The following table summarizes the minimal technical metadata MOAC project partners agreed to capture. All of the fields may be extracted from tiff or jpeg fileheaders using programs with metadata harvester capability such as iViewMediaPro or Canto Cumulus.

File Type	image/tiff
File Dimensions	1024 x 1028 pixels
Sub-object Format	image/tiff, image/jpeg etc.
(Lossless) Compression Format	LZW
Bit Depth	1, 8, 24, etc.
Color Space	CMYK, RGB, CIELab
Resolution	600 dpi; 400 dpi interpolated to 600 dpi
File Date	1999-05-13
File Locator	urn:ucb:I0182A, http://purl.berkeley.edu/I0182A.jpg

The technical metadata captured lives as part of a digital object submitted to the OAC. For more details on the fields and a discussion of encoding the technical metadata accompanying each digital file please see section 4. Digital Objects of this document. Note that in the CDL Digital Object Standard, the fields listed above are dispersed among the Content File Inventory, Structural Metadata and Administrative Metadata - Technical.

G�nter Waibel. Granular Collections Access. An Information Architecture Informed by Standards. Proceeds from Electronic Imaging & The Visual Arts (EVA), 2001 [HTML]

OAC Best Practices Guidelines Version 1.0: Encoding New Finding Aids Using Encoded Archival Description (August 23, 2001) [PDF]

OAC Best Practices Guidelines for Museum Collections Version 1.0: Encoding New Collection Guides Using Encoded Archival Description (May 31, 2002) [PDF]

At the heart of MOAC's strategy for integrating museum collections with library and archival holdings sits Encoded Archival Description (EAD), the common information submission package of the OAC. The standard has its origins in the archival community, and the OAC Best Practice Guidelines (BPG) in effect at the outset of the MOAC project had to be adapted in order to accommodate museum data. As a key outcome of the MOAC project, the consortium established a complimentary mBPG (Museum Best Practice Guideline) for encoding museum collections.

The most noticeable change between the two guidelines occurred at the item level, where MOAC expands the archival BPG to accommodate the project's agreed upon descriptive metadata set. Changes at the higher level of description remain fairly minimal; e.g. the museums reserve the right to repeat certain types of information (such as artist's names and credit lines) at lower levels of the EAD hierarchy. MOAC partners are legally bound to display this type of information whenever a digital image of an item displays. According to archival practice, information always has to appear at its highest appropriate level in the EAD, and may not be repeated.

Another instance of divergent implementation of the EAD: Unlike archival collections, museums put less emphasis on the provenance of a particular collection; similar to museum exhibitions, museum collections organize around a theme or an artist rather than the common origin of materials. The museum BPG produces a valid EAD XML file, and the interoperability between files produced with either BPG remains uncompromised. However, in its details museum mark-up may be at odds with some practices of archival description as established by international standards such as ISAD(G).

MOAC uses EAD XML exclusively as a file exchange format for purposes of data integration among cultural heritage communities, without any implications of providing strict archival description. As a semantic differentiation between archival and museum EAD, MOAC now refers to its EAD XML as "Collection Guides" rather than "Finding Aids."

The museum implementation of the EAD makes extensive use of the opportunities provided by the standard for aggregating and contextualizing objects. At the highest level of description, Museum EAD collection guides typically include a biography of an artist or the history of a movement as well an overview detailing the scope of a collection. They break collections into series, which in turn may contain essays about the particular group of objects gathered under the category in question. At the item-level, contributors have re-used label-copy from exhibitions to provide additional context for an object.

To encode museum data about objects in the EAD, the REACH (Record Export for Art and Cultural Heritage) Element Set was mapped to its appropriate EAD tags. The REACH Element set emerged out of a project initiated by the Getty Information Institute and Research Libraries Group. REACH created a set of 20 elements that are detailed enough to describe an object for researchers, yet simple and generic enough that these fields would be found in most institution's collection management systems. REACH was informed by the more complex Categories for the Description of Works of Art (CDWA) and the Museum Educational Site Licensing Project (MESL) element sets.

The table below is based on Chapter G of the mBPG for Museum Collections and maps the 14 REACH elements deemed relevant by MOAC to their respective EAD encoding tags.

The following codes are used to indicate whether the element is required or not:

REACH Element	EAD Guideline / Mark-up
	If a collection is not subdivided into series and has no file-level descriptions, describe each item-level component using nested Components beginning with <c01>. If a collection does include series and/or file-level descriptions, begin item-level description with the next available <c0x> component. Set the level attribute on all item-level components used to "item". Use an id attribute unique within the OAC environment on all item-level components. This id will be used to link Digital Objects back to the exact location of their description in the collection guide. Until the OAC/CDL makes a programmatic decision on Permanent Object Identifiers (POIs), the use of an institutional acronym and an Accession Number is recommended. Example: <c02 id="bampfa_1996.49.1" level="item">	R
	Use one <did> as the first subelement within all <c0x> tags.	R
Electronic Location & Access	If digital surrogates for the item described exist, provide access to those files through a <daogrp> and nested <daoloc> elements referencing either a single access file, or a separate METS / MOA2 document. Do not use <dao>, even if you only reference a single file. Please note that all external resources referred to in an EAD document have to be declared as entity references (<!ENTITY>) after the document type declaration (<!DOCTYPE>). The name of the entity in the Declaration Subset Area (see Chapter B) has to correspond to the entityref attribute. Using a combination of entityref and href provides two paths for the final display system to access the referenced resource (in this case an image). For a simple reference from an inline thumbnail to an access file, follow Example 1. For a reference from an inline thumbnail to a METS object, follow Example 2. For an example of an entity reference, see Example 3. Example 1: <daogrp><daoloc entityref="bampfa_1994.31_1_2" href=http://www.bampfa.berkeley.edu/ images/bampfa_1994.31_1_2.jpg role="hi-res"></daoloc><daoloc entityref="bampfa_1994.31_1_3" href="http://www.bampfa.berkeley.edu/images/bampfa_1994.31_1_3.jpg" role="thumbnail"></daoloc></daogrp> Example 2: <daogrp><daoloc entityref="bampfa_CC.212_1_2" href="http://sunsite.berkeley.edu/xdlib/servlet/archobj?DOCCHOICE=moac/bampfa_CC.212_moa2.XML" role="hi-res"></daoloc><daoloc entityref="bampfa_CC.212_1_3" href="http://www.bampfa.berkeley.edu/collections/bam/images/moa2/bampfa_CC.212_1_3.jpg" role="thumbnail"></daoloc></daogrp> Example 3: <!ENTITY bampfa_CC.212_1_3 SYSTEM "http://www.bampfa.berkeley.edu/ images/bampfa_CC.212_1_3.jpg" NDATA jpeg>	M
Creator / Maker	Use one <origination> for the person or group responsible for the design or creation of the object. If an individual artist is unknown, this field should contain a designation by school and period or the name of the culture group responsible for the creation of the work. The name should represent the attribution currently accepted by the holding institution. Birth and death dates and country of origin, if known, should go in this field. The ULAN should be used here in conjunction with the NORMAL attribute. Example: <origination><persname role="Creator" NORMAL="Van Gogh, Vincent" source="ULAN"> Vincent Van Gogh, </persname> 1853-1890, Holland </origination>	R
Object Name / Title	Use one <unittitle> for the name or title given to the object by the creator/maker, curator, or owner. Descriptive titles or names based on classification terms or object type may be included here, and must also be included in the 'Type of Object' field (below). Example: <unittitle>Portrait of DeVille</unittitle>	M
Date of Creation / Date Range	Use one <unitdate> with the type attribute set to the appropriate value. To include a bulk date, insert the element <unitdate type="bulk"> immediately after the first <unitdate>.. Example: <unittitle label="Title">Sarah Smith papers, <unitdate type="inclusive">1930-1975</unitdate> <unitdate type="bulk">(bulk 1955-1970)</unitdate></unittitle> If normalizing <unitdate>s using the normal attribute, use ISO 8601 : 1988(E) (available online at: <http://www.iso.ch/markete/8601.pdf>) for determining the format for the attribute value. The following format is recommended: YYYY-MM-DD or YYYY-MM (using 4 digits for years and hyphens between elements). For example, December 12, 1904 would be normalized as "1904-12-12" and April 1962 as "1962-04." Use a forward slash (/) to separate dates in a range, and use the fullest form of the date at each end of the range. For example, normalize August 8-24, 1986 as 1986-08-08/1986-08-24 and November 1923-March 1924 as 1923-11/1924-03.
	Use one <physdesc> following the <unittitle> in the item-level <coX>.	M
Type of Object	Within <physdesc>, use one <genreform> to classify the object by type. For material culture collections, the classification could be the object name (for example, "chair", "canoe", etc.); fine art institutions should use this field to specify object genre or format (for example "painting", "engravings", etc.). Indicate the use of controlled vocabulary by setting the source attribute to the appropriate value. Example: <genreform source="aat">engravings</genreform>	M
Style / Period Group / Movement / School	Within <physdesc>, use one <physfacet> with the type attribute set to "cdwa styles-description" to identify a style or period in the history of art. Preferably, these terms are encoded in AAT with the source attribute set correspondingly to "aat". Time periods such as "19th century" should be included in the Date element. Only periods or movements with proper names should be included as <physfacet>. Example: <physfacet encodinganalog="cdwa styles-description" source="aat">Surrealist</physfacet>	M
Medium / Materials	Within <physdesc>, use another <phsyfacet> with the type attribute set to "cdwa materials-description" to identify the substance(s) of which the object is made or the technique or process used in its creation. Use of controlled vocabulary, with the source attribute set to the appropriate value, is encouraged. Example: <physfacet encodinganalog="cdwa materials-description" source="aat">oil paintings</physfacet>	M
Place of Origin / Discovery	Within <physdesc>, use one or more <geogname> with the role attribute set to the appropriate value to indicate the geographic location in which an object was created, or the location at which the object was found. Use the attribute "cdwa creation-place" and "cdwa context-excavationplace" respectively. Use of controlled vocabulary such as TGN is encouraged, with the source attribute set appropriately. This tag may be especially useful for archaelogical artifacts, while its use for art objects with know creator information is limited. Example: <geogname encodinganalog="cdwa creation-place" source="tgn"> Ib�rica, Pen�nsula </geogname>	M
Dimensions	Within <physdesc>, use one <dimensions> for the measurements of an object. Width, Height, Depth and Circumference should be indicated as w, h, d, c before the actual measurement, as well as the measurement unit (inches or cm). Example: <dimensions>w22 x h37 x d17 cm</dimensions>	M
Current Repository	Use one <repository> for the full name of the current repository of the object; include place if appropriate. The repository name has to be formed according to AACR2 (Chapter 24) catalog entry form. Example: <repository>Berkeley Art Museum/Pacific Film Archive</repository>	R
Current Object ID	Use one <unitid> for the inventory number assigned to the object by the current repository. Preferred use: This field is for the object's accession number or ID number or current inventory number or any unique identifying number as assigned by the current repository. Inventory numbers or other identifiers that may have been assigned to the object by former owners should be reported in the Notes field. Example: <unitid>1958.5.59</unitid>	M
Provenance	Use one <custodhist>, nested in <admininfo>, for the name of the previous owner of an object. Preferred Use: Enter the name of a person, institution, or organization which formerly owned the object (as for example in a credit line), or include current owner's name, especially if different from current repository. Example: <admininfo><custodhist>Gift of Mr. and Mrs. J. Farnsworth </custodhist></admininfo>	M
Notes	Use one or more <odd> elements for a textual description of an object; the object history (associated people, organizations, places, and events in the object's history); distinguishing features; inscriptions/marks; condition; edition/state. Use <odd> for any descriptive text, remarks and comments documenting the object or commenting on it from an interpretive, educational or curatorial perspective. The text has to be specific to the item described in the respective <coX>; group or collection level descriptions should be placed at the appropriate series or subseries level, and not be repeated in each object's <odd>. Notes may be included in the EAD markup (tagged using the <odd> element), or may reside in external text files, linked to from the EAD finding aid (good for very large texts). Use one <head> with an appropriate heading for the type of content encoded. Multiple <odd> entries are distinguished by their different heads. Types of notes may include, but are not restricted to, description/content, inscriptions/marks, state/edition, transcription, history, condition, reference/bibliography, language, exhibition history. Example: <odd><head>Description</head><p>This work epitomizes the ephemeral and spare quality of Cornell's late shadow-boxes and has been linked in influence to minimalism as much as to other art in this particular medium such as the work of Bruce Conner. This work is loosely based on a story of a 19th century Russian ballerina.....</p></odd><odd><head>Condition</head><p>This work has loose nail joints and fragile pigmentation...</p></odd>
Subject	Use one or more <subject> within <controlaccess> for encoding the content or subject matter of the object. Use one <subject> for each term. Indicate the use of AAT or other controlled vocabulary (strongly encouraged) by setting the source attribute correspondingly. Example: <subject source="lcsh">California, Northern; </subject><subject source="lctgm">Events</subject><subject source="lctgm">Fires</subject><subject source="lctgm">Rivers</subject><subject source="lcsh">Sacramento (Calif.)</subject><subject source="lctgm">Settlements</subject></p>

CDL Digital Object Standard: Metadata, Content and Encoding (May 18, 2001) [PDF]

The Making of America II Testbed Project White Paper Version 2.0 (September 15, 1998) [PDF]

The digital object standard Making of America 2 (MOA2) adopted by MOAC serves three broad purposes. First, it allows project members to transfer digital objects to the central repository of the OAC. Second, it provides the means to display all the image files for one record as navigable clusters. In this way, the digital object standard extends the collection guide standard by adding sophisticated display for items represented by more than one image surrogate. Third, the digital object standard ensures the longevity of the digital files created in the project by outlining specifications for minimal technical metadata. In this function, the digital object standard augments the production specifications for digital images.

The UC Berkeley libraries developed MOA2 during a project of the same name as an XML document type definition (dtd), and the CDL subsequently adopted the mark-up as its digital object standard. MOAC reviewed the standard and, with a few exceptions, implemented the minimal set required by the CDL. The following tables and texts have been adapted from Appendix C: Metadata for Digital Objects of the CDL Digital Object Standard. For more details on the encoding of the fields in MOA2 XML, please refer to the original CDL document.

Feature	Example	Description/Comments
Unique identifier reference	urn:ucb:I0182A, 10.1000/I0182A, http://purl.berkeley.edu/I0182A	This element uniquely identifies a particular digital object
Label	Patrick Breen diary : ms., 1846 Nov. 20‑1847 Mar. 1.	Name or title for object, not necessarily unique, for display to user.
Genre	diary, ledger, photoalbum, stereograph, etc.	Class of work of which this digital object is an instance. Analogous to a MARC 655 field.
Descriptive Metadata Reference	http://sunsite2.berkeley.edu:28008/dynaweb/oac/calher/breen/	An identifier or location for descriptive metadata regarding this object.
Descriptive Metadata Type	MARC, EAD, RDF, PICS, OTHER	The form of descriptive metadata associated with this object.

The content file inventory of a digital object contains a listing of all of the files containing digital content derived from the primary source. The metadata elements within the content file inventory contain the most basic information needed to identify, retrieve, and display the content files.

Feature	Example	Description/Comments
Version		A digital library object may encapsulate several different electronic expressions of the original work which has been digitized in different formats. A version within a digital library object consists of all files necessary to process and display a particular expression to a user (e.g., an SGML transcription + DTD +DSSSL style sheet). Files within a single, root <FileGrp> element constitute a digitized version of the object.
File ID	<File ID="I0182A">	A unique identifier, internal to the object, for referencing this particular File from the Structural Map.
File Type	text/xml, text/XML, image/tiff, etc.	Used to inform client software regarding the file's data format, and hence what general viewer type will be needed.
File Sequence	23^rd of 42 page images	Relative position of a particular file within its encapsulating subset of files.
File Date	1999-05-13	The date the file was created expressed as ISO Date Format YYYY-MM-DD
Administrative Metadata Reference	<File ADMID="A125 A137">	This attribute carries information necessary to locate all administrative metadata relevant to this file. In the digital library object, this consists of an IDREF attribute referring to a particular tagged section within the Administrative Metadata portion of the digital library document.
File Use	ARCHIVE, REFERENCE, THUMBNAIL	Used to describe generic instances of an image.
File Dimensions	1024 x 1028 pixels	Dimension information such as the resolution offered by the object (i.e., not the captured resolution) may be provided. This element documents the forms of the image object that can be requested from the repository (i.e., in order to assist an intermediary in navigation, manipulation, etc.). For images of all types (i.e., bitonal and continuous tone), this is resolution and pixel dimensions. The element is not applicable for text.
File Locator	urn:ucb:I0182A, http://purl.berkeley.edu/I0182A.jpg	A unique identifier or locator which may be used by client software to retrieve the file in question.

Structural metadata records the structure of the work from which the digital object is derived. The hierarchy created by structural metadata is crucial for display and navigation of a digital object.

Feature	Example	Description/Comments
Structural Type	Logical, physical, etc.	Structural type is used to indicate whether the internal structure of the object is best described as a logical structure (e.g., this is a diary consisting of entries) or a physical structure (e.g., this is a book consisting of pages).
Structural Divisions/Sub-object Relationships	Parent div of diary, with two child divs of type entry, which are siblings: <div TYPE='diary'> <div TYPE='entry'> </div> <div TYPE='entry'> </div> </div>	A digital object may be logically divided into parts (e.g., letters in a diary). If resources are made available to support some level of encoding, structural divisions are encoded with the TEI element DIV. Many of the attributes of the Digital Object will be applicable to the Structural Divisions. DIVs provide information on sub-object relationships. A diary entry in a diary section (e.g., a year) would have as its parent the section, and would have as siblings the previous and next diary entries. If, for example, it was an unusually long diary entry with sections of its own, its "children" would be the sections within the entry.
Sub-object Type	Table of contents, entry, illustration, etc.	Similar to the genre for an object, sub-object type specifies a class of material of which this sub-object is a particular instance, such as entries in a diary, pages in a photoalbum, etc.
Sub-object sequence	1 - N	Pages require a sequence indicator (e.g., this is the third page in the sequence of pages contained in this book).
Sub-object Label	Page 3, "Fit the Second - The Bellman's Speech"	Name or title for the sub-object, not necessarily unique, for display to user.
Sub-object Format	text/xml, text/XML, image/tiff, etc.

Patch