# Presentation: 702533

## Optional Unit: Specific metadata standards and applications overviews
Addendum to session 4

- Addendum to session 4

**Digital Project Planning & Management Basics**

## Session Objectives

- Understand standards for
- Metadadata elements
-  data value standards
- data content standards and
- Learn about metadata standards developed by specific  communities
- Evaluate the efficacy of the standard for a specific community, their strengths and weaknesses
- Explore the adoption of non-traditional standards by libraries

## Session Outline

- Introduction to basic concepts
- Description of community specific metadata schemes
- Description of specific structural metadata and syntaxes

## Questions to Ask When Selecting a Metadata Standard

- What type of material will be digitized?
- How much information is available?
- Is there a Community of practice developed for this resource type(s)?
- What is the purpose of digital project?
- Did your “Needs Assessment” elicit who will be the audience and how they would use the content?
- Are there pre-existing digital projects with which this one needs to function?
- What Systems options are available?

**Notes:**
Type of material:
Format (photographs, documents, oral histories, raw data)
Complexity of relationships (is it archival in nature and do individual items make sense out of a broader context; is there a hierarchical relationship like photo albums)
Are there multiple versions that need to be displayed

Who is the intended audience and their expectations and usage

## Metadata Standards in a Resource Grid

**Books**
**Journals**

**Special ****collections**

**Freely-accessible web resources**

- high

- low

- low

- high

**stewardship**

**Unique-**
**ness**

**MARC, DC**
**ONIX, MPEG**

**MARC, METS, EAD, DC, TEI**

**DC**

**DC, DDI, IEEE/LOM, FGDC, EAD, TEI, SCORM**

**Institutional assets**

**Books**
**Journals**
**Newspapers**
**Government docs**
**Audiovisual**
**Maps**
**Scores**

**Freely-accessible web resources**
**Open source software**
**Newsgroup archives**

**Special collections**
**Rare books**
**Local/Historical Newspapers**
**Local history materials**
**Archives & manuscripts**
**Theses & dissertations**

**Institutional repositories **
**ePrints**
**Learning objects/materials**
**Research data**

- Stuart Weibel. Presentation **State of the **
**Dublin Core Metadata Initiative **Göttingen August 11, 2003 (Based on Lorcan Dempsey Presentation)

## Metadata Standards

- Schemas (a.k.a. ‘Element Sets’)
- Set of semantic properties, in this context used to describe resources
- Not the same as “XML schemas” (which has a very precise meaning)
- Syntaxes
- The structural wrapping around the semantics
- Essential for moving information around

**Notes:**
Format is a term we are familiar with
DC introduced the term “element set”
We are now calling them “schemas” (emphasizing the systematic idea).  “XML schemas” are not the same thing, they are the structural “template” that allows XML data to be validated.
Syntax allows metadata to be shared, move around, and so forth
Schemas are essential for understanding “what it is” that the metadata is supposed to be doing.

## Content Standards

- AACR2 functions as the content standard for traditional cataloging
- RDA (the successor to AACR2) aspires to be the content standard for non-MARC metadata
- DACS (Describing Archives: a Content Standard)
- CCO (cataloging Cultural Objects) new standard developed by visual arts and cultural heritage community
- Best practices, Guidelines, Data dictionaries-- less formal content standards

**Notes:**
RDA is a work in progress which is more than AACR3 but its focus is still being debated

## Value Standards

- Library of Congress Subject Headings
- Art and Architecture Thesaurus
- Thesaurus of Geographical Names

## Some Example Schemas 

- Dublin Core (_[http://](http://dublincore.org/)__[dublincore](http://dublincore.org/)__[.org](http://dublincore.org/)_)
- Simple and Qualified
- MODS (_[www.loc.](http://www.loc.gov/standards/mods/)__[gov](http://www.loc.gov/standards/mods/)__[/standards/](http://www.loc.gov/standards/mods/)__[mods](http://www.loc.gov/standards/mods/)__[/](http://www.loc.gov/standards/mods/)_)
- VRA 4.0 (_[http://www.vraweb.org/projects/vracore4/index.html](http://www.vraweb.org/projects/vracore4/index.html)_)
- IEEE-LOM (_[http://ltsc.ieee.org/wg12/](http://ltsc.ieee.org/wg12/)_)
- ONIX (_[http://www.](http://www.editeur.org/onix.html)__[editeur](http://www.editeur.org/onix.html)__[.org/](http://www.editeur.org/onix.html)__[onix](http://www.editeur.org/onix.html)__[.html](http://www.editeur.org/onix.html)_)
- EAD _[(](http://www.loc.gov/ead/)__[http://www.loc.](http://www.loc.gov/ead/)__[gov](http://www.loc.gov/ead/)__[/](http://www.loc.gov/ead/)__[ead](http://www.loc.gov/ead/)__[/)](http://www.loc.gov/ead/)_
- TEI _[(](http://www.tei-c.org/)__[http://www.](http://www.tei-c.org/)__[tei](http://www.tei-c.org/)__[-c.org/)](http://www.tei-c.org/)_

## Dublin Core: Simple

- Fifteen elements; one namespace
- Controlled vocabulary _values_ may be expressed, but not the sources of the values
- Minimal standard for OAI-PMH
- Used also as:
- core element set in some other schemas
- switching vocabulary for more complex schemas

**Notes:**
The namespace is where machine (and usually human) readable information can be found.
May use controlled vocabulary but can’t say where the terms come from
(MARC allows different classification and allows the cataloger to say where that classification scheme came from.)
Qualified DC allows the metadata creator to say what kind of controlled vocabulary is used, but not extensively
IEEE-LOM uses simple DC as its core element list
DC is the “lingua franca” for many digital projects.  It doesn’t “map out” (to richer schemas) as well as it “maps in.”

##  2nd W3C Conference Chicago (October 1994)
Conversations at this conference led to the first meeting at OCLC in Dublin Ohio, hence its name
Combination of IT and Librarians

Workshops began in 1995

March 1995, NCSA/OCLC workshop in Dublin, Ohio
Identified the need for author generated metadata, a  “core”: of common elements to describe Web content to help discovery

-  2nd W3C Conference Chicago (October 1994)
- Conversations at this conference led to the first meeting at OCLC in Dublin Ohio, hence its name
- Combination of IT and Librarians
- Workshops began in 1995
- March 1995, NCSA/OCLC workshop in Dublin, Ohio
- Identified the need for author generated metadata, a  “core”: of common elements to describe Web content to help discovery

**Notes:**
The idea was hatched to create a simple set of imbedded elements in HTML pages which would aid search engines to more precisely recall relevant Web pages. Simple enough for non-experts to understand

Its development was for retrieval not what Librarians would call Cataloging which has a broader function. Identification/evaluation/location are dependant how results are displayed: title/description. Indexing by a metatag possible but most search engines ignore. Google recently changed its algorithm to include metatags with Google Scholar. Most people searching the web use 1-2 words, simple non-boolean non-advanced searching.

The original view was that the metatags could be embedded in the HTML (Now in XML, RDF, relational databases)

## “The mission of the Dublin Core Metadata Initiative (DCMI) is to make it easier to find resources using the Internet through the following activities: 

Developing metadata standards for resource discovery across domains     

Defining frameworks for the interoperation of metadata sets   

 Facilitating the development of community- or domain-specific metadata sets that work within these frameworks”  

     Weibel http://purl.org/dc/workshops/dc8conference/plenary/sld018.htm

- “The mission of the Dublin Core Metadata Initiative (DCMI) is to make it easier to find resources using the Internet through the following activities:
- Developing metadata standards for resource discovery across domains
- Defining frameworks for the interoperation of metadata sets
-  Facilitating the development of community- or domain-specific metadata sets that work within these frameworks”**  **
**      **
**     ****Weibel http://purl.org/dc/workshops/dc8conference/plenary/sld018.htm**

## Simplicity
Supports resource discovery
All elements are optional/repeatable
No order of elements prescribed
Extensible* / Refined*
Interdisciplinary/International
Semantic interoperability

- Simplicity
- Supports resource discovery
- All elements are optional/repeatable
- No order of elements prescribed
- Extensible* / Refined*
- Interdisciplinary/International
- Semantic interoperability

**Notes:**
The ability to extend or refine the elements was a point of discussion at many meetings. Implementations that used the 15 elements wished to modify the elements for their special needs by using dot.syntax. By  1998 (DC6) it became clear that many projects were extending the meaning of the basic elements by using the dot.syntax structure. It was recognized that by extending the meaning, it meant that interoperability between databases would be reduced.

Simplicity: can be implemented by non-catalogers; not meant to replace richer description schema. Lower-cost alternative for describing materials
Semantic interoperability: on Internet Commons different schema for describing resources (based  on community/discipline needs: libraries, museums, archives, geospatial information systems. Core attributes, supports cross-file searching

Semantic interoperability - Ability to search for digital information across heterogeneous distributed databases whose metadata schemas have been mapped to one another. It is achieved through agreements about content description standards; for example, Dublin Core, Anglo-American Cataloging Rules.
Syntactic interoperability - Achieved by marking up our data in a similar fashion so we can share the data and so that our machines can understand and take the data apart in sensible ways; for example, XML, EAD and MARC.
Interoperability - The ability of different types of computers, networks, operating systems, and applications to work together effectively, without prior communication, in order to exchange information in a useful and meaningful manner. There are three aspects of interoperability: semantic, structural and syntactical. 
Issues of interoperability: Interpretation and Use of Elements;  Use of Element Qualifiers (Encoding & Refinement); Domain-Specific Elements & Qualifiers; Registry; Search Engine Development; Authenticity
Interdisciplinary/International - Consensus about a simple standard for resource discovery
Mission of the DCMI - The mission of the Dublin Core Metadata Initiative (DCMI) is to make it easier to find resources using the Internet through the following activities: 

Developing metadata standards for resource discovery across domains           
Defining frameworks for the interoperation of metadata sets          
 Facilitating the development of community- or domain-specific metadata sets that work within these frameworks
The ability to extend or refine the elements was a point of discussion at many meetings. Implementations that used the 15 elements wished to modify the elements for their special needs by using dot.syntax. By  1998 (DC6) it became clear that many projects were extending the meaning of the basic elements by using the dot.syntax structure. It was recognized that by extending the meaning, it meant that interoperability between databases would be reduced.

Interdisciplinary/International
Consensus about a simple standard for resource discovery

## International and cross-domain
Increase efficiency of the discovery/retrieval of digital objects
Provide a framework of elements which will aid the management of information
Promote collaboration of cultural/educational information as shared “social capital”

- International and cross-domain
- Increase efficiency of the discovery/retrieval of digital objects
- Provide a framework of elements which will aid the management of information
- Promote collaboration of cultural/educational information as shared “social capital”

## 1:1

Dumb Down

Appropriate Values

**1:1**
**Dumb Down**
**Appropriate Values**

- http://dublincore.org/documents/usageguide/glossary.shtml

**Notes:**
1:1 - whereby related but conceptually different entities, for example a painting and a digital image of the painting, are described by separate metadata records
Describe one manifestation of a resource with one record
Ex.: a digital image of the Mona Lisa is not described as if it were the same as the original painting
Separate descriptions of resources from descriptions of the agents responsible for those resources
Ex.: email addresses and affiliations of creators are attributes of the creator, not the resource

DUMB DOWN: The qualification of Dublin Core Elements is guided by a rule known colloquially as the Dumb-Down Principle. According to this rule, a client should be able to ignore any qualifier and use the value as if it were unqualified. While this may result in some loss of specificity, the remaining term value (minus the qualifier) must continue to be generally correct and useful for discovery. Qualification is therefore supposed only to refine, not extend the semantic scope of an Element.

The fifteen core elements are usable with or without qualifiers.
Qualifiers make elements more specific:
Element Refinements narrow meanings, never extend
Encoding Schemes give context to element values
If your software encounters an unfamiliar qualifier, look it up – or just ignore it!

 Appropriate values - 	Best practice for a particular Element or Qualifier may vary by context. Definitions may provide some guidance; other information may be found in "Using Dublin Core" 

## Dublin Core Metadata Element Set (DCMES) 1996

**Notes:**
By 1996, the 15 elements had been established

kind of extensibility is what I refer to as the LegoTM metaphor–modular extensibility. Let’s say you want additional elements to support local or disciplinary specific requirements. In addition, you want them to be complementary–that is to say, you want them to be able to fit together. So, you might have a block of metadata that we call description metadata, such as the Dublin Core, but you also want species distribution metadata. 

## Ex.: Simple Dublin Core 

- <metadata>
-     <dc:title>**Cataloging cultural objects,**</dc:title>
-     <dc:contributor>**Baca, Murtha.**</dc:contributor>
-     <dc:contributor>**Harpring, Patricia.**/dc:contributor>
-     <dc:subject>**Information organization**</dc:subject>
-     <dc:subject>**Metadata**</dc:subject>
-     <dc:subject>**Cultural property--Documentation**</dc:subject>
-     <dc:subject>**CC135.C37 2006**</dc:subject>
-     <dc:subject>**363.6**</dc:subject>
-     <dc:date>**2006**</dc:date>
-    ** **<dc:format>**396 p.**</dc:format>
-     <dc:type>**Text**</dc:type>
-   **  **<dc:identifier>**ISBN:0838935648**</dc:identifier>
-     <dc:language>**en**</dc:language>
-     <dc:publisher>**ALA Editions**</dc:publisher>
- </metadata>

**Notes:**
There is no prescribed order of elements in DC.  Everything is optional.  Notice that the <subject> element has a classification number in it (this is legal, the distinction between classification and topical subject is at the level of the vocabulary).  This record also has an identifier, the ISBN (this is a physical object, not a digital one)
DC does not specify a particular syntax.

## Extensible architecture
Spectrum of simple to more complex
DCMES may be used with other metadata element sets
LegoTM Metaphor: Modular building blocks used to develop application profiles of mixed metadata
Leverage existing thesauri, classification systems, ontologies, local vocabularies

Stuart Weibel. Presentation State of the 
Dublin Core Metadata Initiative Göttingen August 11, 2003

- Extensible architecture
- Spectrum of simple to more complex
- DCMES may be used with other metadata element sets
- LegoTM Metaphor: Modular building blocks used to develop application profiles of mixed metadata
- Leverage existing thesauri, classification systems, ontologies, local vocabularies
- Stuart Weibel. Presentation **State of the **
**Dublin Core Metadata Initiative **Göttingen August 11, 2003

**Notes:**
Not: “One size fits all”.
Rather: many ways to describe one object:
MARC: complete, for library items
DC: simple, for helping people find things
Terms and conditions: who allowed to use it?
Recognized need: General framework for different types of metadata

## Dublin Core: Qualified

- ‘Qualified’ includes element refinements and encoding schemes
- More specific properties
- Two namespaces
- Explicit vocabularies
- Additional elements, including ‘Audience,’ ‘InstructionalMethod,’ ‘RightsHolder’ and ‘Provenance’

## Qualified Dublin Core

| Elements | Element Refinements |  |
| --- | --- | --- |
| Identifier
Title
Creator
Contributor
Publisher
Subject
Description
Coverage
Format
Type
Date
Relation
Source
Rights
Language | Abstract
Access rights
Alternative
Audience
Available
Bibliographic citation
Conforms to
Created
Date accepted
Date copyrighted
Date submitted
Education level
Extent
Has format
Has part
Has version
Is format of
Is part of
 | Is referenced by
Is replaced by
Is required by
Issued
Is version of
License
Mediator
Medium
Modified
Provenance
References
Replaces
Requires
Rights holder
Spatial
Table of contents
Temporal
Valid
 |

## More Dublin Core “Refinements”

| Encodings | Types |
| --- | --- |
| Box
DCMIType
DDC
IMT
ISO3166
ISO639-2
LCC
LCSH
MESH
Period
Point
RFC1766
RFC3066
TGN
UDC
URI
W3CTDF | Collection
Dataset
Event
Image
Interactive Resource
Moving Image
Physical Object
Service
Software
Sound
Still Image
Text
 |

**Notes:**
Encodings: controlled vocabulary for content
Types are limited to resources
Sheet music and scores are considered image; if with lyrics, repeat
Image jpg
Text jpg

## Ex.: Qualified Dublin Core

- <metadata>
-     <dc:title xml:lang="en">**Cataloging cultural objects.**</dc:title>
-     <dc:contributor>**Baca, Murtha.**</dc:contributor>
-     <dc:contributor>**Harpring, Patricia.**</dc:contributor>
-     <dc:subject xsitype="LCSH">**Information organization**</dc:subject>
-     <dc:subject xsitype="LCSH">**Metadata**</dc:subject>
-     <dc:subject xsitype="LCSH">**Cultural property--Documentation**</dc:subject>
-     <dc:subject xsitype="LCC">**CC135.C37 2006**</dc:subject>
-     <dc:subject xsitype="DDC">**363.3**</dc:subject>
-     <dc:date xsitype="W3CDTF">**2006**</dc:date>
-     <dcterms:extent>**396 p.**</dcterms:extent>
-     <dc:type xsitype="DCMIType">**Text**</dc:type>
-     <dc:identifier xsitype="URI">**ISBN: 0838935648 **</dc:identifier>
-     <dc:language xsitype="RFC3066">**en**</dc:language>
-     <dc:publisher>**ALA Editions**</dc:publisher>
-     <dcterms:audience>**Catalogers**</dcterms:audience>
- </metadata>

**Notes:**
This is a record for the same object as the simple DC record.
Title is in English, that’s what the xml:lang attribute for the title element refers to.
The subject headings came from LCSH, other subject elements are from LCC, DDC
<extent> is a refinement of <format>.  DC does not include hierarchy in its expression.  Your XML schema makes the connection between elements and refinements (ex: <extent> is a refinement of <format>).

## Combining element sets using the Resource Description Framework (RDF), Semantic Web

*Container*

*Package*
- Dublin Core

*Package*
- MARC record

*Package*
- Indirect Reference

*Package*
- Terms and Conditions

- URI

## Advantages of Dublin Core

- Less rigorous content rules
- Easier to train and implement
- Allows OAI harvesting of metadata
- Supported by digital library products:
- ContentDM
- Encompass
- MetaSource

## Disadvantages to Dublin Core

- Lack of granularity may not support specific community needs
- Lack of granularity makes its role as a switching language between standards limited
- No fields are required and lack of consistent training can hamper interoperability

- What is MODS?

- Descriptive metadata standard
- Initiative of Network Development and MARC Standards Office at LC
- A derivative of MARC21
- Documentation refers to MARC definitions for most properties
- Descriptive metadata encoded in an XML schema
- Uses textual rather than numeric tags
- Originally designed for library applications, but may be used for others
- Uses XML Schema (METS)
- http://www.loc.gov/standards/mods/

**Notes:**
Implementation began late 2002 Version 3.0 includes corrections and citation information for journal article
MODS uses a subset of MARC elements.  Elements have been added that were not originally in MARC21.
The development of MODS is not driven by a consensus group, as it is with DC.
Notice also that MODS uses English textual tags instead of the numeric tags used by MARC.  This seems to have been done without much thought of implications for international use.
MODS was developed primarily for bibliographic entities.
MODS now includes affiliation under <name>.

## XML (Extensible Markup Language) is the markup for the Web
Library community need for a element set simpler but compatible with MARC that could be transmitted in XML
A standardized framework for holding and exchanging metadata: analogous to the MARC record, for re-use of pre-existing information
Designed  for complex digital library objects
Dublin Core not sufficient; e.g., need to express role of creator
Provide a more explicit means of expressing different categories of dates in machine-readable forms

- Library community need for a element set simpler but compatible with MARC that could be transmitted in XML
- A standardized framework for holding and exchanging metadata: analogous to the MARC record, for re-use of pre-existing information
- Designed  for complex digital library objects
- Dublin Core not sufficient; e.g., need to express role of creator
- Provide a more explicit means of expressing different categories of dates in machine-readable forms

- Why 			?

## elements

- Title Info
- Name
- Type of resource
- Genre
- Origin Info
- Language
- Physical description
- Abstract
- Table of contents
- Target audience
- Note

- Subject
- Classification
- Related item
- Identifier
- Location
- Access conditions
- Extension
- Record Info
- Root elements:
- mods (A single MODS record
**modsCollection **(A collection of MODS records))

**Notes:**
Higher level genre terms
Elements semantically the same as MARC but there is no assumptions of cataloging rules
Country state city hierarchy for location that is subfielded

## Slide 29

**Notes:**
MINERVA: LC’s web archiving project (based on specific themes)
Exploring issues with born digital resources
MODS used for descriptive metadata
Election 2002 Web archive
Collaboration with Internet Archive, Webarchivist.org 
Selective collection of archived sites July-Nov. 2002
MODS records for each site

## Fields used in Minerva project

- Title
- Alternative title
- Name (structured form)
- Abstract
- Date captured
- Genre (value always “Web site”)

- Physical description (file formats)
- Identifier (base URL)
- Language
- Access conditions/rights management
- Subject (keyword or LCSH if possible)

## Advantages of 

- Uses language-based tags; fully uses Unicode character set
- Allows the aggregation of multilingual records
- Elements generally inherit semantics of MARC but does not assume the use of any specific rules for description
- Element set is more compatible with existing descriptions than ONIX or Dublin Core
- Elements particularly applicable to digital resources
- XML schema allows for flexibility and availability of freely available software tools

**Notes:**
American Memory uses for early american periodical project

## Disadvantages of 

- Library-centric
- Not widely adopted by other libraries or other communities

## Ex.: MODS

-     <titleInfo>
-         <title>**Cataloging cultural objects. /**</title>
-     </titleInfo>
-     <name type="personal">
-         <namePart type="family">**Baca,**</namePart>
-         <namePart type="given">**Murtha),**</namePart>
-         <namePart type="date">**1951-**</namePart>
-         <role>
-             <roleTerm type="text">**editor**</roleTerm>
-         </role>
-     </name>
-     <name type="personal">
-         <namePart type="family">**Harpring,**</namePart>
-         <namePart type="given">**Patricia.**</namePart>
-         <role>
-             <roleTerm type="text">**editor**</roleTerm>
-         </role>
-     </name>

**Notes:**
This is only a snippet of a MODS record, it goes on for several screens.
Note the use of role term (also a new feature of DC)

## More MODS

-     <genre authority="marc">**book**</genre>
-     <originInfo>
-         <place>
-             <placeTerm authority="marccountry" type="code">**ilu**</placeTerm>
-         </place>
-         <place>
-             <placeTerm type="text">**Chicago**</placeTerm>
-         </place>
-         <publisher>**ALA Editions**</publisher>
-         <dateIssued>**2006**</dateIssued>
-         <issuance>**monographic**</issuance>
-     </originInfo>
-     <language>
-         <languageTerm authority="iso639-2b" type="code">**eng**</languageTerm>
-     </language>

**More MODS**

**Notes:**
Notice the <issuance> element, denoting that this item is monographic.

## VRA Core Categories for Visual Resources

- Developed by the Visual Resources Association, the VRA Standards Committee
- Designed specifically for visual resources
- Viewed as a means to share cataloging of visual materials
- Provides access to digitized images and their description

## VRA Metadata Elements

- Based on CDWA for category definitions and recommendations for controlled vocabulary
- Two types of elements
- Work
- Images
- Like DC, all fields are repeatable
- Unlike DC, all are mandatory if applicable

**Notes:**
Work is a physical entity tht exists: painting, music, performance. May be a single item or many parts
Image is a visual representation of a work, including a digital version

Best practices for each element includes:
Indication of qualifiers
Definition
Data values (suggested controlled vocabulary)
Mapping to version 2.0
Mapping to Dublin Core
Mapping to CDWA
Comments
Suggested standards include:
AACR2
AAT
CDWA
LCSH
LCTGM
TGN

## VRA 4.0 Elements

- Work, Collection or Image
- Work Type
- Title
- Measurements
- Material
- Technique
- Agent
- Date
- Subject
- Relation

- Location REFID
- Text REF
- Style/Period
- Agent.Culture / Cultural Context
- Description
- Source
- Rights
- Inscription
- State Edition

**Notes:**

Agent = Creator

Location REFID
Text REF (an ID not associated with holding institution)

## VRA Data Values

- LCSH
- AAT
- TGN
- ULAN

## Online Information Exchange (ONIX)

- 	Designed by publishing industry (American Association of Publishers) to exchange information about “books” with wholesalers, retail, e-tail booksellers.
- Standard for data exchange
- Richer information for online bookstores

## ONIX Integrated with MARC Records?

- 	CC:DA Task on ONIX International charge with reviewing the standard and assessing the impact if integrated
- 	http://www.ala.org/alcts/organization/ccs/ccda/tf-onix1.html

**Notes:**
Committee on Cataloging: Description and Access (ALCTS committee with ALA)

## Comparison of ONIX & MARC

- ONIX has finer granularity than MARC
- Fields can be mapped from ONIX into UNIMARC, but can not be reconverted
- Each application contains fields that are relevant to only themselves
- ONIX records provide enriching information: reviews, abstracts,TOC, prizes won, credentials of authors

**Notes:**
ONIX: height, width, depth, weight type of packing for shipping
Price Composite; rights/distribution to different countries; Out of Print Date

## ONIX/MARC Crosswalks 

- ONIX (1.0) to UNIMARC Crosswalk developed by Library of Congress
- 	http://lcweb.loc.gov/marc/onix2marc.htlml
- Mapping by Bob Pearson (OCLC)
- 	http://222.editeur.org/ONIX_MARC_Mapping_External.doc
- Report by Alan Danskin
- 	http://bic.org.uk/reporton.doc

## ONIX Metadata Standard

- 	Allows two levels of description:
- Level 2:
- 235 elements of information in 24 categories
- Requires XML DTD
- Level 1:
- Not all the categories, 82 elements
- Does not require XML DTD

**Notes:**
Level 1 designed for publishers without an in-house information management database
UK/US have slightly different core elements (45 considered core)

## ONIX for Books

- Originally devised to simplify the provision of book product information to online retailers (name stood for ONline Information eXchange)
- First version flat XML, second version included hierarchy and elements repeated within ‘composites’
- Maintained by Editeur, with the the Book Industry Study Group (New York) and Book Industry Communication (London)
- Includes marketing and shipping oriented information: book jacket blurb and photos, full size and weight info, etc.

**Notes:**
Briefly.
It’s hard to map a second hierarchical version.  ONIX includes a lot of marketing text and information helpful to shipping, e.g., taxes in different jurisdictions, height and weight.

## Ex.: ONIX

**<Title>**
**<TitleType>**01**</TitleType>**
**<TitleText textcase = “02”>**British English, A to Zed**</TitleText>**
**</Title>**
**<Contributor>**
**<SequenceNumber>**1**</SequenceNumber>**
**<ContributorRole>**A01**</ContributorRole>**
**<PersonNameInverted>**Schur, Norman W**</PersonNameInverted>**
**<BiographicalNote>**A Harvard graduate in Latin and Italian literature, Norman Schur attended the University of Rome and the Sorbonne before returning to the United States to study law at Harvard and Columbia Law  Schools. Now retired from legal practise, Mr Schur is a fluent speaker and writer of both British and American English.**</BiographicalNote>**
** ****</Contributor>**

**Notes:**
Note the encoded values (TitleType, SequenceNumber, ContributorRole).  Hard to figure out the encoding without looking it up (same for MARC).  This information is all in one, big package.

## Ex.: ONIX

**<othertext>**
**<d102>**01**</d102>**
**<d104>**BRITISH ENGLISH, A TO ZED is the thoroughly updated, revised, and
- expanded third edition of Norman Schur’s highly acclaimed transatlantic dictionary
- for English speakers. First published as BRITISH SELF-TAUGHT and then as
- ENGLISH ENGLISH, this collection of Briticisms for Americans, and Americanisms
- for the British, is a scholarly yet witty lexicon, combining definitions with
- commentary on the most frequently used and some lesser known words and
- phrases. Highly readable, it’s a snip of a book, and one that sorts out – through
- comments in American – the “Queen’s English” – confounding as it may
- seem.**</d104>**
**</othertext>**
**<othertext>**
**<d102>**08**</d102>**
**<d104>**Norman Schur is without doubt the outstanding authority on the similarities
- and differences between British and American English. BRITISH ENGLISH, A TO
- ZED attests not only to his expertise, but also to his undiminished powers to inform, amuse and entertain. – Laurence Urdang, Editor, VERBATIM, The Language
- Quarterly, Spring 1988 **</d104>**
**</othertext>**

**Notes:**
Numeric tags get away from language limitations.

## Ex.: ONIX

**<othertext>**
**<d102>**01**</d102>**
**<d104>**BRITISH ENGLISH, A TO ZED is the thoroughly updated, revised, and
- expanded third edition of Norman Schur’s highly acclaimed transatlantic dictionary
- for English speakers. First published as BRITISH SELF-TAUGHT and then as
- ENGLISH ENGLISH, this collection of Briticisms for Americans, and Americanisms
- for the British, is a scholarly yet witty lexicon, combining definitions with
- commentary on the most frequently used and some lesser known words and
- phrases. Highly readable, it’s a snip of a book, and one that sorts out – through
- comments in American – the “Queen’s English” – confounding as it may
- seem.**</d104>**
**</othertext>**
**<othertext>**
**<d102>**08**</d102>**
**<d104>**Norman Schur is without doubt the outstanding authority on the similarities
- and differences between British and American English. BRITISH ENGLISH, A TO
- ZED attests not only to his expertise, but also to his undiminished powers to inform, amuse and entertain. – Laurence Urdang, Editor, VERBATIM, The Language
- Quarterly, Spring 1988 **</d104>**
**</othertext>**

**Main Desc.**

**Review**

**Notes:**
Yellow bubbles tell you what the codes mean.

## EAD -- Encoded Archival Description

- http://www.loc.gov/ead/

## Learning Object Metadata 

- An array of related standards for description of ‘learning objects’ or ‘learning resources’
- Most based on efforts of the IEEE LTSC (Institute of Electrical and Electronics Engineers Learning Technology Standards Committee) and the IMS Global Learning Consortium, inc.
- Tends to be very complex with few implementations outside of government and industry
- One well-documented implementation is CanCore

**Notes:**
This standard was developed by IEEE.
The IMS Global Learning Consortium is a sort of spin-off.
Look at the CanCore implementation, which is really one of the few IEEE-LOM that we can examine.  Usage of IEEE-LOM tends to be in closed government sites, for example, Army training manuals.
IEEE-LOM is very rich in its way, but it’s a real commitment.

- http://www.loc.gov/standards/mix/

- XML schema for a set of technical data elements required
-  to manage digital image collections

## TEI -- Text Encoding Initiative

- http://www.tei-c.org/