PBCore v2??

For full documentation of PBCore elements, on an element-by-element based, select an entry from the index of metadata descriptors on the left-hand side of this page.

Listed below are other sections of the PBCore User Guide that document the elements.

	Element Documentation
	Of interest to information specialists is the Full Documentation for the PBCore elements. If you are looking for a one-page quick reference for the definitions of each element and some data examples, use the Cheat Sheet. Other documentation is provided to round out the understanding of PBCore's metadata elements.
		Full Documentation
		Cheat Sheet for Elements
		Attributes of Elements Explained
		Content Classes Described
		Element Containers Described
		Metadata Examples
		XML Schema Definition (XSD)
		XML Primers
		Hierarchies & Element Interdependencies
		Mappings & Crosswalks
		Namespace for PBCore
		Glossary of Metadata Terms
	Element Views
	Different ways to examine the PBCore elements, with active links to each element's definition and description.
		Quick Index View
		Graphical View
		Content Class View
		Alphabetical View
		Mandatory Elements List (obligation to use)
		Changes for PBCore v1.1

EXPLANATORY NOTES for v2...

1. Format Technical Details Repeat
for Essence Tracks belonging to an Instantiation

pbcoreEssenceTrack is a new sub-container for the container pbcoreInstantiation.

The recommendation for change is precipitated by difficulties in describing technical details about a media item. Specifically, and as an example, a single digital instance or rendition of a media item may have a video track, an audio track in English, an audio track in Spanish, and a captioned text track. Each track has its own unique technical specification, e.g., the video track has its own data rate, as do the audio tracks. The audio tracks also have sampling rates that are unique to digital audio, but unimportant to video tracks.

Ideally, each track of a media item can have its technical details captured by its own sub-container with its own relevant metadata elements. Thus, the creation of the sub-container pbcoreEssenceTrack within the larger parent container, pbcoreInstantiation.

A preliminary examination shows that some metadata elements are relevant for the media item essence as a whole, with all of its combined essence tracks. Other metadata elements are strictly relevant to a specific essence track. And yet others, such as data rate (and a gaggle of others), could be argued that they exist BOTH for the essence as a whole AND for specific essence tracks. Thus, metadata elements with similar meaning but differentiated by their ownership within a container or sub-container must be accommodated. These technical bits get rather complex and hierarchical in nature in order to represent them all in a meaningful way.

The reorganized elements within the parent container pbcoreInstantiation and the child sub-container pbcoreEssenceTrack are outlined to the left (just a suggestion).

For illustrations of the evolution of PBCore from v1.0 to the newest proposals, see the diagrams below. Click on the thumbnail diagram to view a higher resolution version in a separate browser window.

PBCore v1.0 (the original release, April 2005)

4 Content Classes 0 Element Containers 0 Sub-Containers 49 Elements

PBCore v1.1 (publlshed Jan 2007)

4 Content Classes 15 Element Containers 3 Sub-Containers 53 Elements

PBCore v2.1 (proposal A)

4 Content Classes 15 Element Containers 4 Sub-Containers 66 Elements

PBCore v2.2 (proposal B)

4 Content Classes 15 Element Containers 4 Sub-Containers 61 Elements

essenceTrackType identifies which component/track of the whole media item is being described.

• essenceTrackType picklist (a starter list of possible values)
  1. video
  2. audio
  3. text
  4. caption
  5. subtitle
  6. metadata
  7. sprite
  8. timecode

As you can see, elements with similar meanings now exist both at the parent level and at the sub-container, essenceTrack level; they may be different.

All of this is ripe for discussion. Such structural alterations of course cascade into changes for...

• the PBCore XSD
• the PBCore User Guide
• the PBCore Cataloging Tools and its import/export features
• end-user training and familiarization with these changes
• existing mapping and crosswalk documents
• existing sample metadata records

2. Persistent Metadata related to Original Source

Need a place to indicate the date the “intellectual content” was made: for example, “Gone With the Wind” filmed in 1936. Takes place in 1865. So coverage.temporal  = 1865. Our instantiation is a VHS version,  and the VHS was made in 1990. Then dateCreated = 1990. But where do you indicate that the “intellectual content” was made in 1936?

3. Instantiations composed of Multiple Physical Items

Need a good way to represent instantiations consisting of more than one physical item. For example, we have video of an event on campus, shot in Betamax. The master spans 2 Betamax cassettes. However, there is nowhere to indicate that the Betamax/master instantiation comprises 2 physical items.

4. Recursive Description for Components of an Asset - the "Structure Map" Issue

[Comments from Grace Agnew]

The need to support recursive, linked descriptions for subsets of a production is an issue you are already considering.  The cleanest way to approach it would be to create a second schema, “pbcoreStructureMap” and change the current schema to pbcoreDescriptionDocument”.  The current Schema 1.0 would become the pbcoreDescriptionDocument and Schema 2.0 would reference both the pbcoreStructureMap and the pbcoreDescriptionDocument schemas  Schema 2.0 may include structureMap  and descriptionDocument subschemas  and define how they relate to each other, a la the METS document schema, or it may create the structureMap within the 2.0 schema  by establishing asset types and restrictive subelements (start and stop time codes, duration)  as elements of PBcore 2.0 and then reference and apply the descriptionDocument subschema, as a repeatable subschema under each asset within the structure map.

This strategy will enable all of your legacy users to migrate their data to 2.0 with little or no problem.  Their current descriptions are at the production asset level, and they would be essentially adding a structure map and the ability to describe sub-assets to their existing description.  Their underlying database would need extension but they wouldn’t lose any data and their workflow wouldn’t change appreciably since they would be leveraging their current knowledge base, since the DescriptionDocument would transfer en toto to the new schema.

5. Map to PREMIS Metadata Schema

[Comments from Grace Agnew]

Another next step would be to map to the PREMIS schema and probably extend the Rights and Instantiation elements to insure that required elements are supported.  There aren’t that many required elements, but there are some elements specific to preservation that are currently lacking in PBCore.