Go to home page for the PBCore



Go to home page for PBCore

Go to User Guide for PBCore

PBCore in Use

 

The PBCore XML Schema Definition (XSD)

Context
Get the PBCore XML Schema Definition (XSD)
PBCore Diagram -- At-a-Glance
XML Schema Primers

 

 


CONTEXT:

Knowledge Representation: A metadata schema, as well as the actual descriptions of media items that may use the schema, need to be presented in some logical, clearly expressed framework so that the information can be understood, either in a human-readable form or machine or computer-readable.

Interchange Structure: More importantly, using well-formed methods and frameworks to express metadata schemas and descriptions allows different parties to share data; they are communicating using the same language, the same grammar, and the same structuring of data.

A language that is often used in files to express well-formed data is XML, Extensible Markup Language. Unless the party offering and the party accepting the well-formed data interpret, validate, and implement that data in the same way, information is likely to be mangled. Four conditions have been itemized in describing common data interpretation, validation, and implementation between systems sharing information:

  1. common metadata meanings (semantics),
  2. common grammar and rules for expressing data (syntax),
  3. commonly defined metadata dictionary element properties (attributes), and
  4. shared information architectures concentrating on entities with their hierarchical structures and interdependencies (data models)

Items 1 through 3 (semantics, syntax, and attributes) are usually referred to as the Metadata Dictionary. Item 4 is the expression of the Metadata Dictionary within a data model's framework. A DTD (Document Type Definition) and an XML Schema are used to define the grammar and validate the data being shared. Some have stated that DTDs and XML Schemas function as blueprints for describing the structure of the XML language in a document. These blueprints supply the...

  • Sequence in which elements appear in an XML document
  • Interrelationships between different elements (interdependencies, parent-child associations or nested relationships)
  • Types of data that are used to express elements and attributes (text string, number, date, timestamp, etc.)

DTDs have been around longer than XML Schemas, and are very widely used. However, they have some limitations in their capacities, such as using non-XML syntax to compose a DTD, support for limited data types, inability to identify namespaces (see What is a Namespace?), and no support for extensibility or inheritance. XML Schemas, however, do not have these limitations, and also allow users to craft their own data types.

Typically, more complex data structures, with multiple data types, require the use of an XML Schema over that of a DTD.

PBCore is offering an XML Schema Definition (XSD) document to define the framework of the PBCore elements and their inter-relationships and interdependencies (see the download links below). For further discussion in element hierarchies and interdependencies, see our web page Information about Hierarchical Relationships & Interdependencies Between Metadata Elements.

TWO SCENARIOS FOR DATA SHARING...
When sharing metadata and facilitating interoperability, data that is exported from an information system (one metadata island) is transformed into a PBCore compliant XML document, using the framework of the PBCore XSD. The receiving information system (another metadata island) imports the PBCore compliant XML document and transforms that data to match its own internal structures and metadata schemas.

The following discussion highlights two different scenarios in which data is being exchanged between information systems.

SCENARIO 1:

Station A uses an In-House tool to create and save descriptive records for its media assets. This tool can export the records as XML compliant with the PBCore XSD.

Station B uses the PBCore Project's Cataloging Tool to create and save descriptive records of its media assets. This tool can import and export metadata records as XML compliant with the PBCore XSD.

Data Sharing with no data transformation necessary

 

SCENARIO 2

Station X purchased a tool (System X) to create and save descriptive records for its media assets. This tool cannot export the records as XML (in Format X) that are compliant with the PBCore XSD.

Station Y purchased a different tool (System Y) to create and save descriptive records of its media assets. This tool cannot import or export the records as XML (in Format Y) that are compliant with either the PBCore XSD or Format X.

Because the respective stations use tools that utilize records in different formats, they cannot exchange records without first transforming them into a new format that can be understood by both tools.

The PBCore XSD can be used to move data between the two incompatible systems.

Station X uses a transformation method (such as XSLT--Extensible Stylesheet Language Transformations; W3C or Wikipedia definition) to translate records from Format X into PBCore XSD-compliant data.

Station Y transforms the PBCore XSD-compliant data into Format Y before importing the records into System Y.

Data Sharing with data transformations

 

Within an individual Public Broadcasting station, there are many departments, each maintaining their own data islands that facilitate their individual departmental functions and missions. PBCore compliant XML documents could act as the data transformation framework that allows the different systems to share data. Here is an example of a typical Public Broadcasting TV station's metadata islands.

PTV station metadata islands

There are many metadata schemes available for use by various industries and communities, each with their own set of elements and definitions.

The creation of a "Namespace" that is referenced by schema makers and schema users is done in order to distinguish one set of element names from another set used by a different schema. For example, the element "description" may have divergent meanings from one set of metadata to another. Two or more developers may be using an identical element name.

By declaring a formal Namespace in which a specific metadata schema declares the existence and meaning of its metadata elements and names, we avoid name collisions and confusion.

A Namespace declares a "bread crumb trail" between real world applications of a schema's metadata and its humble origins...or at least it points to the party responsible for its creation in the first place. Declaring a namespace is extremely important when creating an XML Schema Document. In such documentation, it is vital to avoid collisions.

A concise discussion is available in an article from the Wikipedia, entitled XML Namespace. In a nutshell, the article states:

An XML Namespace is a W3C standard for providing uniquely named elements and attributes in an XML instance. An XML instance may contain element or attribute names from more than one XML vocabulary. If each vocabulary is given a namespace then the ambiguity between identically named elements or attributes can be resolved.

A very brief Tutorial about XML Namespaces is available from the w3schools website. One intriguing concept of XML Namespaces is as follows:

Note that the address used to identify the namespace is not used by the [XML] parser to look up information. The only purpose is to give the namespace a unique name. However, very often companies use the namespace as a pointer to a real Web page containing information about the namespace.
Try to go to http://www.w3.org/TR/html4/.

 

 

 

 


DOWNLOAD THE PBCORE XSD (XML Schema Definition):

The XSD (XML Schema Definition) for the PBCore metadata dictionary is now available for use. When migrating metadata from one information system (metadata island) to another system (metadata island), the PBCore XSD defines the structure and organization of the data exported from the source system. The PBCore XSD assists the information system importing the data by providing the consistent structure needed to re-transform the data to match that of receiving system.


Get the PBCore XSD v1.1 text document download the PBCore XSD (XML Schema Definition)(October 2007)(XSD Text document, zipped)

XML Text Document view the PBCore XSD (XML Schema Definition)(October 2007) directly within a web browser page

...once this document is opened in your web browser,
some browsers require you to VIEW > SOURCE
in order to see the proper XML format.

 

Other Resources...

Download the PBCore FileMaker Pro Cataloging Tool
FileMaker Pro PBCore Cataloging Tool
(currently in beta testing; posts October, 2007)
Documentation for the PBCore Cataloging Tool
Documentation for the FileMaker Pro PBCore Cataloging Tool
(currently in beta testing; posts October, 2007)
PBCore Training Session 104: the PBCore Cataloging Tool
Learn More: PBCore Training Session 104: the PBCore Cataloging Tool
PBCore Training Session 103: the PBCore XML Schema
Learn More: PBCore Training Session 103: the PBCore XML Schema
Learn about XML documents and Schema Definitions
Learn More: XML & XSD Primers & Tutorials
PBCore Case Examples
Learn More: PBCore Case Examples of PBCore in Use
PBCore Sample Metadata Records
Learn More: PBCore Sample Metadata Records & Descriptions
PBCore User Guide and Dictionary Definitions
Learn More: PBCore User Guide and Dictionary Definitions
PBCore Training Session 102: the PBCore Metadata Elements
Learn More: PBCore Training Session 102: the PBCore Metadata Elements
Mappings of PBCore to other Metadata Standards
Learn More: Mappings of PBCore to other Metadata Standards
Join the PBCore User Group Community
Learn More: Join the PBCore User Group Community

 

PBCore Diagram -- At-a-Glance

The hierarchical branches, and leaves of the PBCore framework are alternatively expressed in our data model as "Master Container," "Content Classes,' "Containers," "Sub-Containers," "Elements," and "Sub-Elements." PBCore has 53 elements, associated with 15 containers and 3 sub-containers, all organized under 4 content classes.

PBCore DESCRIPTION DOCUMENT (aka the MASTER CONTAINER)
The Master Container assembles together all collections of PBCore knowledge items. For PBCore these knowledge items are metadata descriptions of media. The MasterContainer is expressed as a document that hierarchically structures all the knowledge items and metadata terms and values related to a single data record associated with a media item. In our XML Schema Definition, the MasterContainer is referred to as the "PBCoreDescriptionDocument."

CONTENT CLASS (aka PBCore Section)
In the hierarchy of objects in the PBCore Description Document/Master Container, Content Classes are created as "conceptual wrappers" that cluster together a list or structure of thematically-related Elements (metadata fields and their attributes and properties). PBCore maintains four Content Classes as the conceptual wrappers for its various metadata elements:

  1. PBCoreIntellectualContent
    9 containers; 16 elements
    (metadata elements describing the actual intellectual content of a media asset or resource)
  2. PBCoreIntellectualProperty
    4 containers; 7 elements
    (metadata elements related to the creation, creators, usage, permissions, constraints, and use obligations associated with a media asset or resource)
  3. PBCoreInstantiation
    1 container, 3 sub-containers; 28 elements
    (metadata elements that identify the nature of the media asset as it exists in some form or format in the physical world or digitally)
  4. PBCoreExtensions
    1 container; 2 elements
    (additional descriptions that have been crafted by organizations outside of the PBCore Project. These extensions fulfill the metadata requirements for these outside groups as they identify and describe their own types of media with specialized, custom terminologies unique to their needs and community requirements)

ELEMENT CONTAINERS & SUB-CONTAINERS (aka Schema Tag and Schema Sub-Tag, alternatively "branches"):
Elements are objects in the PBCore schema hierarchy that define a metadata field and its values, attributes and properties. An element may be standalone. If several metadata fields are thematically related to each other, they can be bound together under an Element Container. Related elements are subsumed by a larger theme, and should be bound together when data is shared (particularly if an Element Container is a repeatable description with multiple instances of its related Elements). Examples of related Elements bound within a Container are *title* and its associated *titleType*, that are bound together by the Element Container *PBCoreTitle*. Within hierarchical structures, a Container may house Sub-Containers, which themselves bind together related Elements. In PBCore, there are Sub-Containers found within the Content Class PBCoreInstantiation.

ELEMENTS (aka "leaves"):
Elements are objects that define a metadata field and its values, semantics, attributes, and properties (for a list of the attributes defined for PBCore elements, see our web page PBCore Element Attributes). An Element is the actual "thing" that carries the descriptive metadata about a media item, such as a title, a date, keywords, rights information, mime types, media types, etc. The metadata elements are what a cataloger interacts with (creating descriptions) within a cataloging tool or asset management system.

Accommodating Content Classes, Containers, and Elements, the PBCore begins to look like the following diagram (click on the image to see a higher resolution version):


PBCore Diagram of Element Relationships

Open a separate browser window
with a higher resolution version of the
PBCore Hierarchy Diagram.


 

When the actual PBCore elements are integrated into a database and its associated cataloging application or digital asset management system, the "presentation" of the elements to the cataloger who is providing and entering metadata descriptions may not necessarily look exactly like the Hierarchy Diagram for PBCore. Often, the features and capabilities of a particular information management system require metadata elements to be displayed or function in specific ways. The actual "application" of the PBCore metadata elements may vary from the strict framework of the hierarchy or data model.

However, if metadata is to be shared, it is vital that the system's metadata is exported according to the framework of the PBCore XML Schema Definition. This export may require some transactions or transformations to be conducted on the existing metadata. But when accomplished, the exported metadata becomes a "known" and "validated" data document that a receiving information system can accurately interpret and import into its particular structures and applications.

XML transactions take place on exports from information systems. Likewise, they take place on the import of data into information systems. But at least they are conducting transactions on a commonly defined and understood XML Schema Definition.

 

 


XML SCHEMA PRIMERS:

Listed here are Primers, XML Schema Definitions and Specifications as provided by W3C

 

 

 

 

PBCore in Use

 

Provide feedback

 

Go to CPB website

© 2005 Corporation for Public Broadcasting
- CPB Privacy Policy -
- PBCore Licensing via Creative Commons -