MOAC Technical Specifications

Specifications for submissions of finding aids, imaging metadata, and images from museums to the Online Archive of California

Approved by MOAC Committee on Jan. 25, 2000

Contents:

Museums submitting collections information for inclusion in the Online Archive of California may submit 3 kinds of content. Finding aids are required; images are optional. If images are included then both images and image metadata must be included.

1. Finding Aids (descriptive data). Must be encoded in the EAD SGML DTD according to the specifications outlined below in section 1.

2. Image Metadata (metadata). Must be encoded in the MOA XML DTD according to the specifications outlined below in section 2.

3. Image Specifications (image files). May be sent to OAC or hosted on local museum server. Must comply with specifcations outlined below in section 3.


 

Finding Aids

(Markup of item-level records - EAD container lists)

These records will usually be exported from databases where the information is already structured, rather than marked up manually. These specifications can be used to markup automatically when exporting from databases, using scripts on records exported as text, or for manual markup.

Below, each "field" of markup is addressed separately, including notes on the use of related structural and terminology standards, with an example of a completed record at the end.

Related Standards Used:

REACH Element Set

The number (target set) and definitions (content standards) of fields of data to include in item level records were derived from the REACH Element Set. The REACH (Record Export for Access to Cultural Heritage) was a project initiated by the Getty Information Institute and Research Libraries Group, which included several cultural heritage institutions. The REACH project created a set of elements that were determined to be detailed enough to describe an object for researchers and yet simple and generic enough that these fields would likely be found in most institution's collection information systems, even with minimal cataloging, and so make an ideal target for describing objects in a union-database environment. The REACH element set was designed partially as a distillation of the more complex, exhaustive CDWA and MESL element sets, and in relation to the Dublin Core element set (REACH has been called a "DC for cultural objects").

The definitions of the element set below does not override the definitions for the equivalent EAD elements, but rather provides content guidelines for what to bring into those EAD elements, and describes that content more in terms of how it may be used in the database source for mapping and conversion purposes.

Controlled Vocabularies

AAT (Art & Architecture Thesaurus), ULAN (Union List of Artist Names), TGN (Thesaurus of Geographic Names), LCTGM (Library of Congress Subject Heading Thesaurus for Graphic Materials). These terminology standards, all developed largely by the museum and library communities, are used in print and database collection systems to provide consistency of terms for access purposes. These authority sources will be used whenever possible inside the marked/fielded data elements. The EAD offers very consistent ways to include both unstructured terms and structured terms, either exclusively or together in a record, as described in the examples below.

 

 

Elements/Fields:

These fields should be included in the order shown. Elements are named, then defined as they would be found in a database system, then the EAD markup is shown. This set (based on REACH) is a target or template for markup of item-level records. However if an institution lacks data for one or more fields, it should simply be omitted. If the institution needs to add more than this number of fields, they should consult with the OAC project team on how best to include that. To repeat any element (such as Subject) repeat the tag for each instance as well.

Start and End item-level record:

At the point in the finding aid container list where the item-level record occurs (<c01>, <c02>, etc) the "level" attribute should be set to "item". Items are the most detailed description allowed in the EAD, and thus items should not include other items in the container list heirarchy. If one has several items to describe, each should have its own <c0x> element. An item level record would thus occur as:

<c0x level="item">

elements described below (or subset)

</c0x>

Name

Req

Description

EAD Examples

Electronic Location & Access

Only if image is present

The entity reference or URL linking the object record to a digital image of the object or the filename for that digital image. Repeatable for multiple, different images of object. If you have thumbnails of images, and then larger versions, it’s preferrable to have the thumbnail be the image which displays on the page, and is linked to the larger image. To enable this, always place the thumbnail image second in markup order.

<daogrp>

<daoloc entityref="b1968.79-1a" role="hi-res"></daoloc>

<daoloc entityref="b1968.79-1t" role="thumbnail"></daoloc>

</daogrp>

Note that image file names are referred to with entityrefs. Entityrefs should be declared for each image earlier in the EAD document (immediately after <!DOCTYPE…. and before the first <ead> tag) with this syntax:

<!ENTITY b1965-6a SYSTEM "http://www.bampfa.berkeley.edu/images/1968.79.a.jpg" NDATA JPEG>

Entityrefs are required for each image. It is also allowable (optional) to include an additional, HREF type linking mechanism in the markup like this:

<daogrp>

<daoloc entityref="b1968.79-1a" href ="http://www.bampfa.berkeley.edu/images/" role="hi-res"></daoloc>

<daoloc entityref="b1968.79-1t" href ="http://www.bampfa.berkeley.edu/images/" role="thumbnail"></daoloc>

</daogrp>

The examples above assume one image (two resolutions) per item. However, it may also be the case that several images, such as different sides of an object, are included in the item record. In this case, the daogrp is repeated for each image. The following markup represents two images of one item, each with two resolutions available:

<daogrp>

<daoloc entityref="b1968.79-1a" href="" role="hi-res"></daoloc>

<daoloc entityref="b1968.79-1t" href="" role="thumbnail"></daoloc>

</daogrp>

<daogrp>

<daoloc entityref="b1968.79-2a" href="" role="hi-res"></daoloc>

<daoloc entityref="b1968.79-2t" href="" role="thumbnail"></daoloc>

</daogrp>

Creator/Maker

Yes, even if 'unknown'

The name of a person or group responsible for the design or creation of the object. Where 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, after the name. The ULAN may be used here in conjunction with the NORMAL attribute.

<origination><persname> Vincent van Gogh, </persname> 1853-1890, Holland</origination>

or

<origination><persname role="Creator" NORMAL="Van Gogh, Vincent" source="ULAN"> Vincent Van Gogh, </persname> 1853-1890, Holland </origination>

Object Name/Title

Only if present in museum record

The name or title given to the object by the creator/maker, curator, or owner, or the text of a caption that appears with the image as in

prints, cartoons, and photographs. Preferred Use: The field for a title or name of the object. Descriptive titles or names based on classification terms or object type may be

included here, and must be included in the 'Type of Object' field (below).

<unittitle> Portrait of DeVille </unittitle>

Date of Creation/Date Range

Yes, even if 'unknown'

The year in which the object was created; if specific year not known, or if object executed over several years, give date range. Circa, BCE., and ca. may be used to indicate approximate dates for objects (ca.1999), however c1999 or ©1999 should be used only for copyright dates for published materials.

<unitdate> 1897</unitdate>

or

<unitdate norm="1801-1900"> 19th century</unitdate>

Place of Origin/Discovery

No

The geographical location in which an object was created, or if not known, then place object was found. Especially useful for archaeological artifacts, not so useful for art objects where creator info is known.

<geogname role="Creation-Place" source="CDWA"> Iberian Peninsula</geogname>

or

<geogname role="Context-Excavationplace" source="CDWA"> Iberian Peninsula</geogname>

Medium/Materials

Only if present in museum record

The substance(s) of which the object is made or the technique or process used in it's creation.

<physfacet> oil on canvas</physfacet>

or

<physfacet> bronze vessel creating using lost-wax method </physfacet>

or

<physfacet type="Materials-Description" source="CDWA"> oil on canvas</physfacet>

Dimensions

Only if present in museum record

Measurements associated with any particular dimension of the object. Hieght, Width, Depth, or Length should be indicated. Measurement unit should also be indicated.

<dimensions>w22 x h37 inches</dimensions>

or

<dimensions>w22 x h37 x d17 cm</dimensions>

Current Repository Name

Yes

The full name of the current repository of the object; include place if appropriate.

<repository> Berkeley Art Museum</repository>

Current Object ID Number

Only if present in museum record

The inventory number currently 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.

<unitid> 1958.5.59 </unitid>

Creditline/

Provenance

No

The name of a previous owner of the object.

Preferred Use:

Enter the name of a person, institution, or organization that

formerly owned the object or include current owner’s name, especially if different from current repository.

<admininfo>

<custodhist> Gift of Mr. and Mrs. J. Farnsworth </custodhist>

</admininfo>

or

<admininfo>

<custodhist> On Extended Loan to the J. Wright Estate </custodhist>

</admininfo>

Notes

No

Textual description of object; object history: associated people, organizations, places, and events in the object's history; distinguishing features; inscriptions/marks; condition;

edition/state. Any descriptive text, remarks and comments documenting the object or commenting on it from an interpretive or curatorial perspective. For this purpose, this text should be only that which is specific to this item; group or collection level descriptions should be placed above the group of objects being described, and not repeated in each object’s <odd> (other descriptive data) field. 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).

<odd><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>

Multiple, separate notes should be distinguished by the addition of a <head> sub-element like this:

<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>

Types of notes may include description/content, inscriptions/marks, state/edition, transcription, history, condition, reference/bibliography, language, exhibition history, etc.

Subject Matter

Only if present in museum record

The content or subject matter of the object. AAT or other authority source for term is encouraged here.

<subject>madonna and child</subject>

Type of Object

Yes

The classification of the object by type.

This field is for the term(s) that indicate the classification of the object. For material culture collections, this will tend to 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, engraving, etc.). AAT or other authority source for term is encouraged here.

<genreform> canoe </genreform>

or

<genreform> engraving</genreform>

or

<genreform source="AAT" norm="engravings"> engraving</genreform>

Style/

Period/

Group/

Movement/

School

No

A term identifying a style or period in the history of art. This field is for the term(s) identifying a style or period whose

characteristics are represented by the object. These terms should preferably be in the AAT, except where the AAT is too Western Art

centric. Time periods , per se, such as "19th century" should be included in the Date element. Only periods or movements with proper names should be included here.

<physfacet type="Styles-Description" source="CDWA"> Surrealism </physfacet>

 


 

Image Metadata

 

Metadata and Encoding Tables

These tables are intended to be the set of metadata elements approved by the MOAC committee for use by MOAC partners in the management of a digital image collection. These elements are a sub-set of the CDL imaging metadata specifications (see http://www.ucop.edu/irc/cdl/tasw/Current/current.html), and include all CDL elements which are listed as required in those specs for full compliance. MOAC partners will likely use either the FileMakekr or Access version of the Digital Asset Management Database to manage this data. Much of this being automatically generated from pre-defined defaults; some will require hand-entry as part of the scanning process. The Columns of the table are:

  1. Element: the name of the metadata element
  2. Example: examples of this element’s content
  3. Description/Comments: a definition of this metadata element
  4. Req: Shows if the metadata element is required
  5. There are currently 20 required metadata elements, two of which need to be manually input for each object. The other elements would normally be automatically generated or inherited from "default" fields set in digitization management software.

  6. Rep: Shows if the element is repeatable
  7. Source: Given reasonable digitization management software, the column describes how the element is created (e.g., manually supplied, automatically generated)
  8. Element / Attribute: Shows where this element is encoded in the XML DTD

These metadata elements provide descriptive information regarding the entirety of a digital object. The descriptive metadata actually stored within a digital library object is minimal; most of the descriptive metadata regarding the object is stored externally to the object and is only referenced (or, in Warwick Framework terms, is an indirect package).

 

Example

Description/Comments

Req.

Rep.

Element/ Attribute

Unique identifier reference

urn:ucb:I0182A, 10.1000/I0182A, http://purl.berkeley.edu/I0182A

This element uniquely identifies a particular digital object

Yes

No

OBJID attrib. of ArchObj. element

Label

Patrick Breen diary : ms., 1846 Nov. 20-1847 Mar. 1.

Name or title for object, not necessarily unique, for display to user.

Yes

No

LABEL attrib. of ArchObj element

Genre

diary, ledger, photoalbum, stereograph, etc.

Class of work of which this digital object is an instance. Analogous to a MARC 655 field.

Yes

No

TYPE attrib. of ArchObj element

Descriptive Metadata Reference

http://sunsite2.berkeley.edu:28008/dynaweb/oac/calher/breen/

An identifier or location for descriptive metadata regarding this object.

Remarks:

Because MOA2 docs didn't have desc. metadata, this pointed to the MARC record, an EAD finding aid, etc which did. With our new finding aids, the MOA2 doc will live inside a finding aid so this is implied.

(2) Descriptive metadata reference does sit in the database, as the finding aid and MARC record fields in the tblObject table. These fields should contain a URN or URL that can be used to retrieve the finding aid that describes this object or MARC record that describes this object. Descriptive metadata type is generated automatically by the MOA2 generator, although it's pretty limited in its evaluation at this point. Basically, it looks at the beginning of each field, and if it sees "http" it assumes it's a URL, and if it sees "urn:" it assumes its a URN.

The structure of descriptive metadata tends to be unique within an intellectual domain. The archival community, for example, uses the EAD standard for descriptive metadata. The bibliographic community uses MARC records. The scholarly publishing community is in the process of developing their own standard. The underlying assumption here is that very little descriptive metadata is generally stored with the digital object itself. The metadata associated with the object is generally administrative and structural, used to control when and how the object is used, and to define the context in which the object should be presented. Search and retrieval is generally a separate function, supported by external descriptive metadata. If no such separate package of descriptive metadata exists, it could either be created now, or a simple set of descriptive terms could be added to the CDL DTD. Many users will probably encode Dublin Core within the DTD.

should be presented. Search and retrieval is generally a separate function, supported by external descriptive metadata. If no such separate package of descriptive metadata exists, it could either be created now, or a simple set of descriptive terms could be added to the CDL DTD. Many users will probably encode Dublin Core within the DTD.

Yes

Yes

DMDRef Element and possibly TAGID Attribute of DMDRef element

Descriptive Metadata Type

MARC, EAD, RDF, PICS

The form of descriptive metadata associated with this object.

Remarks:

This describes what the above resource is: MARC record, EAD finding aid, etc.

Yes

No

DMDTYPE Attribute of DMDRef element

 

The content file inventory of a digital library object contains a listing of all of the files containing digital content derived from the primary source. The files are grouped within <FileGrp> elements. Root <FileGrp> elements encapsulate particular digital versions of the material (so that the files comprising an SGML transcription would be in one <FileGrp>, for example, while those comprising a series of page images would be in another). Subsidiary <FileGrp> elements may be used to divide files within a version according the nature of their content (so that all page image files would be in subsidiary <FileGrp>, while details from individual pages would be in another). The metadata elements within the content file inventory contain the most basic information needed to identify, retrieve, and display the content files which compose a digital object.

Feature

Example

Description/Comments

Req.

Rep.

Element/ Attribute

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.

Remarks:

What version of the file is it: thumbnail, master, text: smg, text: xml which we designate by a letter appended to the filename.

A version in both the MOA2 and CDL world consists of a file or group or files which together constitute a complete digital representation of an object. So, a complete

set of TIFF master page images would constitute a version, a set of derivative JPEG page images would constitute a second version, an SGML transcription (and necessary related entity files, if any) would constitute another, etc. In our database, all master images for an object are grouped into one version when being dumped into a MOA2 document. Derivative images actually have a version field that can be set and is used to group derivatives into versions (<fileGrp> elements) when producing the MOA2 document. All SGML transcription files for an object are grouped into another version; this last part is probably the most questionable aspect of the database and MOA2 generation program, but at this point, I haven't heard of anybody preparing multiple SGML transcriptions for an object, so I'm not worrying about it.

(2) Versions are assigned letters (a, b, c, d) which are incorporated in the filenames immediately preceding the dot. So, a master image would be mastera.tiff, while a deriviatve JPEG would be mastera_a.jpeg, and a derivative gif from the same master would be mastera_b.gif.

The version tag was intended to distinguish among multiple representations of the same underlying physical object. So, yes, different screen display resolutions would be different versions of the same underlying object. That's a very simple example, though, and generally version information wouldn't be necessary for such self-contained instances. The problem that the version tag was really meant to address is that of versions which require multiple parts to display, such as an SGML transcription of a document, plus its DTD, plus the associated style sheet for rendering. The optical scan of the document would be another version, and an audio or video recording might be a third. I'm going to defer your question about derivation of this information from the subobject hierarchy to Bernie Hurley, as I think that was his idea.

Yes

Yes

Root FileGrp element

File ID

<File ID="I0182A">

A unique identifier, internal to the object, for referencing this particular File from the Structural Map.

Yes

No

ID Attribute on File element

File Type

text/sgml, 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.

Yes

No

MIMETYPE attribute on File element

File Sequence

23rd of 42 page images

Relative position of a particular file within its encapsulating subset of files.

Yes

No

SEQ attribute on File element

File Date

1999-05-13

The date the file was created expressed as ISO Date Format YYYY-MM-DD

Yes

No

CREATED attribute on File element

File Use

ARCHIVE, REFERENCE, THUMBNAIL

Used to describe generic instances of an image.

Yes

No

USE attribute on File element.

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.

Yes

No

FLocat element

 

 

 

Structural Metadata Table

Structural metadata records the abstract structure of the work from which the digital object is derived. Digital library objects are all structured as some type of hierarchy. Structural metadata is crucial for display and navigation of a digital object, as well as for indicating the relationships which exist between different digital versions of the same work.

Feature

Example

Description/Comments

Req.

Rep.

Element/ Attribute

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).

Remarks:

This describes what type of structural hierarchy you are making. We don't have any clear differentiation for this in the DB. I think it is just implied for finding aids by level attributes.

this is the type attribute on the <StructMap> element in the MOA2 DTD. It is supposed to record whether the hierarchy of subobjects contained within an object depict a logical decomposition of the document (e.g., a book with chapters) or a physical one (e.g. a book with pages). There is no specific element in the DB recording structural type, and I didn't really feel like trying to code an intelligent agent to guess based on the complete set of subobject types included in the hierarchy, so at the moment, the MOA2 generator codes all produced documents as having a logical hierarchy (since it's what you *should* be doing), and people can edit the resulting document by hand if it's not accurate.

(2) Display of an object in the MOA2 browser will always be a tree; labelling the tree as logical or physical doesn't make much difference, and in fact, many trees end up being a bit of both. If it had been entirely my choice, I probably would have jettisoned the distinction, but I was not in charge of delineating the metadata elements for MOA2, just supporting them in XML.

A bound book is a physical structural type, while a sheaf of loose sheets that are intellectually related is a logical structural type. I can't think of any other types besides physical and logical. Perhaps metaphysical, for structure that only exists in the mind of the beholder?

Yes

Yes

TYPE Attribute of StructMap element

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.

Remarks:

This is the parent child relationship set up by the "parent" field, as far as I know.

a structural division is a line between two subobjects in an object. The subobject hierarchy in the DB determines all of the divisions.

Structural Divisions: if I understand you correctly, there is not

>field in the db for this info, since it already is contained in the

>subobject hierarchy. Once we export into MOAII, the export >calculation throws in a <div> between subobjects, with TYPE being >what we capture in the SubObjectType field, and that's that. Correct >me if I am wrong!

>

This field is intended to capture finer granularity than book/chapter/page. Some objects may have multiple logical divisions within one of those physical divisions, and that's what the Structural Divisions/Sub-object Relationships field is for. The <div> tag was offered as a specific example (from TEI) of this type of field, where multiple entries on a page of a diary might be encoded as separate <div>s.

Yes

Yes

div element

 

Feature

Example

Description/Comments

Req.

Rep.

Source

Element/ Attribute

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).

Yes

No

Automatically generated

N attribute on div element

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.

Yes

No

Manually supplied in data capture

LABEL attribute on div element

Sub-object Format

text/sgml, text/xml, image/tiff, etc.

Images of all types (e.g., page images and continuous tone images) require format information. The contents of the Sub-object Format element are coordinated with the Content Type element (see above). While Content Type declares the available formats for a particular "type" of information (e.g., encoded text), the Sub-object Format element refers to these declarations to inform the intermediary of the available formats for the object at hand. For example, a page image may be said to be available as a GIF image, a PDF file, and a TIFF G4 image.

Yes

No

Automatically generated from defaults

MIMETYPE attribute on fptr element

Sub-object reference

<fptr FILEID="I0182A">

This attribute carries information needed to locate the sub-object. In the digital library object, this consists of an IDREF attribute referring to a particular file within the File Inventory section, possibly combined with a reference to a tagged item within a file.

Yes

Yes

Automatically generated

FILEID attribute and possibly TAGID attribute of fptr element

 

Administrative Metadata Table - General

Administrative metadata encompasses all information necessary for objects' long term use and management. It includes information on the technical features of content files (sometimes called technical metadata), intellectual property rights information, and source and provenance information.

Feature

Example

Description/Comments

Req.

Rep.

Element/ Attribute

Administra-tive Metadata ID

<AdminMD ID="AM183">

A unique identifier, internal to a digital library object, which allows this metadata to be referenced by other portions of the object

Remarks:

We have several administraive fields. I believe this is just an external pointer to that data if it resides somewhere other than with the MOA2 object, as in a finding aid.

This does not reside in the DB, but is

dynamically generated by the MOA2 generator program. It's nothing but a string used to uniquely identify an element within the resulting XML document (i.e., it's an XML ID attribute value).

(2) An administrative metadata ID pertains to a particular bit of administrative metadata within the MOA2 document, and hence, there can be a large number of such IDs within any give MOA2 doc. If you had a master image, and two derivatives, say, the master and each derivative would probably all have separate administrative metadata sections describing how image capture and conversion were done for that particular version. In addition, there were would be ad administrative metadata section for intellectual property rights that would probably cover all three versions. Each admin. metadata section would have its own ID attribute on the xml element <adminMD> that encompassed that section. Each <file> element (elsewhere in the MOA2 document, would reference one or more adminMD IDs to identity which administrative metadata sections were pertinent to that file. A file element for a master image, for example, would reference the IDs for the administrative metadata sections for the master image capture and intellectual property rights. This referencing is done by another attribute on the <file> element, called ADMID, which you should see mentioned in the CDL DTD.

The purpose of having a separate ID for this information is to allow other processes/objects to directly access the administrative metadata for a given object, particularly if that information is stored as a reference, and not within a single large XML document. If you're not using that kind of indirection, you should be OK reusing the subobject ID.

No, our assumption is that for a large number of images (say, all your

derivatives of one type a great deal of your administrative metadata will be identical (capture DPI, scanner, light source, etc.). So, you enter this info once in your DB, and it gets kicked out once into an <adminMD>

element in your document, which all of your derivative files are linked to

(via an IDREFS attribute on the <file> element). This is a *big* space savings on objects with a lot of image files. Ditto intellectual property rights info. You can record it in a single <adminMD> element, which all of your files link to. In short, administrative metadata for files is usually not unique.

Yes

No

ID Attribute of AdminMD element

 


 

Administrative Metadata Table - Technical

Technical administrative metadata elements include that information necessary to document the technical processes employed in both digitizing primary source material and storing the digitization for future use (e.g., photographic and imaging processes and file formats used for storage).

Feature

Example

Description/Comments

Req.

Rep.

Element/ Attribute

(Lossless) Compression Format

LZW

Type of algorithm needed to decompress the image, with note of software package used to apply the format, and degree/percentage of compression used where options exist.

Yes

No

Compression element

Color Space

CMYK, RGB, CIELab

Color space used, often needed by viewer and indicates whether image was initially created for onscreen display or for pre-press output. (Some color space parameters such as white point may require individual tags).

Yes

No

ColorSpace element

 

Administrative Metadata Table - Rights

Rights administrative metadata elements include information regarding the intellectual property rights relevant to the digital object's storage, transmission and use.

Feature

Example

Description/Comments

Req.

Rep.

Source

Element/ Attribute

Owner

Saskia

Owner(s) of the copyright on the digital image file, which MAY be the creator of the digital image file, or the person(s) from whom the digital image file was purchased or licensed. It should contain the name(s) of the person(s) from whom copy/distribution and display/transmission rights may be secured. Note: this refers to the copyright on the digital image only, not the work(s) represented in the digital image.

No

Yes

Automatically generated from defaults

Owner element

Credit Line

Copyright Berkeley Art Museum, 1978. All rights reserved.

The text required to be displayed whenever the image/data appears.

Yes

No

Automatically generated from defaults

Credit element

Copying & Distribution Restrictions

Copy and distribution of this file is prohibited without the express written consent of...

text that spells out any copyright restrictions pertaining to the copy and distribution of this image file.

No

No

Automatically generated from defaults

CopyRest element

Display & Transmission Restrictions

This file may be displayed or transmitted across a network only by person(s) who have signed a license agreement with ...

text that spells out any copyright restrictions regarding the transmission and display of this image file.

No

No

Automatically generated from defaults

DispRest element

 

Administrative Metadata Table - Source

Source administrative metadata elements are intended to record all information necessary to determine the origin of the current file, including both the sources used to produce the current file and any transformations which were applied to the content of the file in moving from an earlier version to the current resource. By preference, source information will be chained together so that an unbroken path from the existing file back to the original primary source material from which it derives can be traced.

Feature

Example

Description/Comments

Req.

Rep.

Element/ Attribute

Source Item ID

a local catalog number plus page number for a book; an accession number (and possibly a page or part number) for a special collections item

A number or alphanumeric string uniquely identifying the source of this file (recursively).

Yes

No

SOURCEID Attribute of Source element

Source Type

Photographic print, slide, manuscript, printed page(s), another digital image

To identify the material from which the digital file was created - the item on hand, even if it itself is a reformatted version, e.g. the scan of a 35mm slide of a painting would be entered here as a 35mm slide.

Yes

No

Type subelement of the Source element

Physical Dimensions of Source

10.2cm x 18.4cm

Actual physical dimension of source. Needed for appropriate facsimile output.

Yes, if avail

No

X, Y and UNIT Attribute of OrgDimen element

 


 

Image Specifications

 

These specifications outline the requirements for digital images which will be delivered as part of MOAC partners' finding aids via the Online Archive of California website. These specifications are based on the CDL specifications (see http://www.ucop.edu/irc/cdl/tasw/Current/current.html) and meet those minimum requirements as well. For the MOAC project (and resource within the CDL OAC) MOAC recommends that images created before Jan. 1, 2000, which will be included in some MOAC finding aids, be 'grandfathered in' even if they do not meet the following specifications. Images created after Jan. 1, 2000 which are included in the MOAC resource must meet the following specifications. Some MOAC images will be stored centrally on the CDL server, and others will be stored de-centrally, and served directly via the MOAC partner's own server.

• If images are included, the partner must provide at least two versions of each image: a thumbnail image for inline viewing and one size larger for reference.

• MOAC recommends that some imaging metadata be presented to the viewer when they click on the thumbnail and get the next size larger image. Such metadata might include scan source, so that the viewer would know if the image was obtained from a photographic print or the object itself. So, the EAD descriptive data would be presented alongside the thumbnail inline and always be the first level of information given about an object/image, but the larger image and imaging metadata would be available as a second-layer of information.

• Archive or Master images should be at least 3000 pixels along the longest edge, no matter what the source of the digital image is (8ft painting photographed with a digital camera, or 35mm slide of a painting put on a scanner).

• Master images should be stored in the TIFF format with no compression. Thumbnails should be stored in JPEG (JFIF) format. Intermediary images, served by a MOAC partner directly off their server, may be in other formats, pending discussion with CDL. For instance, some MOAC partners serving images from their own servers, may want to deliver MrSID or Flashpix images which allow zooming.

• A color or grayscale bar is required in the Master image, and optional in other size images for access.

 

Resolution

Format

Bit-Depth

Gamma

Master Image

3000 pixels at least longest edge(no matter source size)

TIFF (no compression)

24 bit color for color sources

8 bit grayscale for b/w sources

2.2

Intermediaries

Anything over 150 pixels longest edge

Optional.

JPEG, QTVR, Flashpix

24 bit color for color sources

8 bit grayscale for b/w sources

2.2

Thumbnail Image

150 pixels exactly longest edge

JPEG (JFIF)

24 bit color for color sources

8 bit grayscale for b/w sources

2.2