My slides are available here: NHF_PBCore_WGBH.pdf

My co-presenter’s slides are available here on the web site of Northeast Historic Film.

PS: There’s still time to register for the next PBCore Workshop coming up in November at the Association of Moving Image Archivists conference in Austin, Texas, taught by public media colleagues Jack Brighton, Kara Van Malssen, Dave Rice and Brian Graney.

**The PBCore listserv will be discontinued on July 31, 2011 in order to migrate to a free and open platform.**

PBCore Talk web address: http://groups.google.com/group/pbcore-talk
PBCore Talk email address: pbcore-talk@googlegroups.com

Access:
- Anybody can view group content
- Only members can view group members list
- Anyone can join
- Only members can post

We hope this new platform will be a great venue to continue to share information and resources about PBCore and its continued use and development.

Join the PBCore Listserv

pbcore-talk@googlegroups.com

To subscribe: join the PBCore-Talk Google Group at http://groups.google.com/group/pbcore-talk. Please contact us with any questions.

To post a message: send a message to pbcore-talk@googlegroups.com

To switch to digest mode: go to the PBCore-Talk Google Group site and click on “edit my membership,” select “digest email” and then “save these settings.”

To unsubscribe: go to the PBCore-Talk Google Group site and click on “edit my membership,” select “unsubscribe.”

It is a bit unusual to approach a metadata standard like it were an open source application, but we found GitHub to be helpful in our process for developing PBCore 2.0 and we think it could be even more helpful in sustaining the effort going forward.

What can you do with PBCore 2.0 on GitHub?

You can download the XSD schema

Although, you should actually use the official version from this site.

You can submit issues that you have with PBCore 2.0.

As part of the process for developing PBCore 2.0 we solicited Changes Requests from the community of users. Many of these request have been lingering for years, but this was the first time anyone had made an effort to collect them in one place. And ongoing change requests can be gathered here to inform future versions of PBCore.

Of course, you can still use the comment function of this web site to submit requests, but if you prefer a more formal “issue” format, use the Issue tracker at GitHub

You can branch PBCore2.0 and submit patches to it.

If there’s something in the XSD (or in the support documents in the repository) that you think should be changed, please go ahead and change and push your changes back to us. When the next version of PBCore is released, we’ll evaluate any and all patches that are submitted

And for those of you interested in history, you can see some of the iterations that PBCore went through as it progressed from 1.3 to 2.0

It ain’t pretty and mistakes were made. But if you really want to know why we made the decisions we made, it’s (mostly) all there in the repository.

We are pretty excited about this latest use of social technology to support PBCore, and we hope it will contribute to the robustness and sustainability of the standard. If you have any thoughts on this development — good idea, bad idea, other ideas — please share them in the comments below.

The panel was mostly focused on case studies of collaboration — including examples between radio & print, amongst television & the arts community, and between media makers.

PBCore is more of an enabling technology than an example of collaboration, but I managed to fit in with the rest of the panel by describing how PBCore 2.0 was a combined effort by many folks in public broadcasting, including radio, television and online. I also threw in a few details about some of the tools we used to collaborate — from this blog, to Google Docs, to GitHub.

PBCore presentation for IMA 2011 Conference

Here are two examples

PBCore embedded in Atom

(Accessed through an OpenSearch API)

OpenSearch is an open API for documenting and exposing search query interfaces. Although it supports any data format for query responses, this example uses the Atom format (similar to RSS and compatible with most feed readers), with embedded PBCore records.

The American Archive Content Inventory Project has an OpenSearch interface, which is described at http://americanarchiveinventory.org/catalog/opensearch.xml

You can craft queries that return pbcore metadata by adding content_format=pbcore to the query string. For example, the following URL returns pbcore metadata about items in the CPB collection (assuming you are logged in with appropriate credentials).

http://americanarchiveinventory.org/catalog.atom?content_format=pbcore&forganization_name_facet=Corporation+for+Public+Broadcasting

PBCore accessed through OAI

The OpenArchives Initiative is a collection of APIs and protocols designed to support the harvesting of metadata over the web.

The American Archive Content Inventory Project has an OpenSearch interface. By using the OAI identify verb, you can get basic information about the collection and OAI interface:

http://americanarchiveinventory.org/catalog/oai?verb=Identify

You can retrieve a list of records in the PBCore format by using the listRecords verb along with metadataPrefix=pbcore (assuming you are logged in with appropriate credentials):

http://americanarchiveinventory.org/catalog/oai?verb=ListRecords&metadataPrefix=pbcore

If metadata to describe the content of each tape (i.e., the program segment material) is not needed, then the program can be described generally at the level of element ‘pbcoreDescriptionDocument,’ and each of its multiple carriers noted most simply by the repeated use of the sub-element structure within pbcoreInstantiation. For example:

<?xml version="1.0" encoding="UTF-8"?>
<pbcoreDescriptionDocument xmlns="http://www.pbcore.org/PBCore/PBCoreNamespace.html"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.pbcore.org/PBCore/PBCoreNamespace.html>
<pbcoreIdentifier source="MARS">XYZ123</pbcoreIdentifier>
    <pbcoreTitle>XYZ123:  The Program</pbcoreTitle>

<!-- section removed for clarity -->

    <pbcoreInstantiation>
        <instantiationIdentifier source="MARS">XYZ123-A</instantiationIdentifier>
        <instantiationLocation>VAULT</instantiationLocation>
        <instantiationRelation>
            <instantiationRelationType annotation="One of a multi-part instantiation">Precedes in Sequence</instantiationRelationType>
            <instantiationRelationIdentifier source="MARS">XYZ123-B</instantiationRelationIdentifier>
        </instantiationRelation>
    </pbcoreInstantiation>
    <pbcoreInstantiation>
        <instantiationIdentifier source="MARS"></instantiationIdentifier>
        <instantiationLocation>VAULT</instantiationLocation>
        <instantiationRelation>
            <instantiationRelationType annotation="One of a multi-part instantiation">Follows in Sequence</instantiationRelationType>
            <instantiationRelationIdentifier source="MARS">XYZ123-A</instantiationRelationIdentifier>
        </instantiationRelation>
        <instantiationRelation>
            <instantiationRelationType annotation="One of a multi-part instantiation">Precedes in Sequence</instantiationRelationType>
            <instantiationRelationIdentifier source="MARS">XYZ123-C</instantiationRelationIdentifier>
        </instantiationRelation>
    </pbcoreInstantiation>

<!-- section removed for clarity -->

</pbcoreDescriptionDocument>

If descriptive metadata about the program material is needed at the level of the tape, then use pbcoreDescriptionDocument as before, but with sub-elements ‘pbcorePart’ instead of ‘pbcoreInstantiation.’ There, data about each tape would be contained within pbcorePart structures, each with a ‘pbcoreInstantiation’ assemblage:

<?xml version="1.0" encoding="UTF-8"?>
<pbcoreDescriptionDocument xmlns="http://www.pbcore.org/PBCore/PBCoreNamespace.html"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.pbcore.org/PBCore/PBCoreNamespace.html>
<pbcoreIdentifier source="MARS">XYZ123</pbcoreIdentifier>
    <pbcoreTitle>XYZ123:  The Program</pbcoreTitle>

<!-- section removed for clarity -->

    <pbcorePart startTime="00:00:00" endTime="00:29:50">
        <pbcoreIdentifier source="MARS">XYZ123-A</pbcoreIdentifier>
        <pbcoreTitle>XYZ123: The Program Part One</pbcoreTitle>
        <pbcoreDescription>The stage is set for conflict between X, Y and Z</pbcoreDescription>
        <pbcoreInstantiation>
            <instantiationIdentifier source="MARS" annotation="One of a multi-part instantiation">XYZ123-A</instantiationIdentifier>
            <instantiationLocation>VAULT</instantiationLocation>
            <instantiationRelation>
                <instantiationRelationType annotation="One of a multi-part instantiation">Precedes in Sequence</instantiationRelationType>
                <instantiationRelationIdentifier source="MARS">XYZ123-B</instantiationRelationIdentifier>
            </instantiationRelation>
        </pbcoreInstantiation>
    </pbcorePart>

    <pbcorePart startTime="00:29:50" endTime="00:59:40">
        <pbcoreIdentifier source="MARS">XYZ123-B</pbcoreIdentifier>
        <pbcoreTitle>XYZ123: The Program Part Two</pbcoreTitle>
        <pbcoreDescription>The forces of X, Y and Z combine to shake the world</pbcoreDescription>
        <pbcoreInstantiation>
            <instantiationIdentifier source="MARS" annotation="One of a multi-part instantiation">XYZ123-B</instantiationIdentifier>
            <instantiationLocation>VAULT</instantiationLocation>
            <instantiationRelation>
                <instantiationRelationType annotation="One of a multi-part instantiation">Follows in Sequence</instantiationRelationType>
                <instantiationRelationIdentifier source="MARS">XYZ123-A</instantiationRelationIdentifier>
            </instantiationRelation>
        </pbcoreInstantiation>
    </pbcorePart>

<!-- section removed for clarity -->

</pbcoreDescriptionDocument> 

The PBCore schema is the blueprint for organizing a specified set of metadata when expressed as XML. We might have a media catalog that holds our metadata in a database, or a simple spreadsheet with titles, descriptions, etc. In fact many of us will probably always use various databases and desktop tools to form the core of our media asset management systems. PBCore XML provides a common format for these systems to talk to each other and share metadata.

The PBCore schema serves as a guide for developers of applications that “speak PBCore.” The schema also makes it possible to automatically validate PBCore records and ensure data compatibility between systems.

What’s New in 2.0

Since its introduction in 2005, PBCore has gained wide acceptance because it provides a thorough yet simple way to describe media assets. The 2.0 schema builds on the main PBCore elements without compromising its ease of use. That said, those familiar with PBCore 1.x will recognize significant differences:

• The addition of optional attributes in many elements.
• The ability to describe “multi-part instantiations,” i.e. a single media production comprised of more than one film, tape, or file.
• The inclusion of rights information at the Instantiation level, not just the Intellectual Description level.
• The option to include markup from other existing rights metadata standards, e.g. ODRL or Creative Commons.
• A simple way to show relationships between Instantiations, for example that an MPEG4 Instantiation was encoded from a QuickTime Instantiation.
• The ability to specify time-based metadata within an asset, e.g. where exactly in the timeline a particular subject is discussed or a specific person appears.
• New core elements that resolve thorny issues encountered by PBCore users: pbcoreAssetType allows you to indicate the “broad editorial format” of the asset, e.g. a program, a clip, an episode, or a scene.
• pbcoreAssetDate provides, for the first time, a way to specify the creation date of the asset, not just its Instantiations.
• It is now valid to have an asset with no Instantiations, so you can have an Intellectual Description of an asset for which no Instantiations yet exist. And conversely, you can have an Instantiation Only asset with the new root tag pbcoreInstantiationDocument.
• The addition of a new pbcoreCollection element allows the wrapping of many pbcoreDescriptionDocuments in a collection of assets for easy exchange with other systems. You can now have a PBCore “feed,” and use PBCore in RESTful web applications.
• A new pbcorePart element allows for defining segments, stories, and clips within an asset, and nested relationships between assets and asset parts.
• Extensions are now available at the Asset, Instantiation and EssenceTrack level, and can include metadata and markup from other standards.

Toward a more semantic web

Since 2004, PBCore has been used as a standard to catalog media and exchange metadata. It has been adopted by a growing number of public media organizations, film archives, academic institutions, and technology vendors. But until now, there was no direct way to connect PBCore metadata to the growing universe of linked data on the web.

The introduction of optional attributes in the 2.0 schema clears the way for true PBCore semantic web applications. For example, we can specify a subject term and include not just the name of a subject authority, but the URI to an authoritative subject definition. Other resources on the web that are linked to that subject term can now be related to our media asset. We can also include link attributes for pbcoreCreators and pbcoreContributors, pbcoreRelations, and many other elements.

As more PBCore assets include such unambiguous links to subject terms, people, and other media assets, it becomes possible to crawl and map many such relationships. For example, a lecture by Langston Hughes can automatically link to other Langston Hughes-related resources. By using the new “ref” attribute to specify URIs for PBCore element values, we make our media assets part of the expanding universe of linked data and semantically-enabled content.

Keeping it simple enough to use

The required core elements of PBCore have not changed in the 2.0 schema. Attributes, collections, and parts are all optional. In fact, PBCore still requires only three elements: Identifier, Title, and Description; all other elements are optional. PBCore 2.0 retains the simplicity of PBCore 1.x and remains faithful to its origins in Dublin Core.

What the 2.0 schema does is fix problems identified by the PBCore user community. Many people contributed change requests, blog posts, questions, commentary, criticism, and research. The development and review teams solicited additional feedback on early versions. As they work with PBCore 2.0, users will undoubtedly discover things that can be further refined and improved. The PBCore 2.0 Schema is the result of a true community effort, and that effort should continue.

You will discover more as you explore PBCore 2.0 and begin using it with your assets and collections. The Schema Review team believes this release is a huge step forward to improve the standard, but as always, we look forward to your comments.

Abstract:
In less than ten years, broadcasting has been completely transformed from an analog media to a production and distribution environment that is digital from end-to-end. Early in the transition, the public broadcasting system recognized the need for a single, unified metadata schema able to deliver digital content across multiple platforms. The Public Broadcasting Metadata Dictionary Project (PBMD), comprised of representatives from both public radio and public television, was convened by the Corporation for Public Broadcasting in 2001 and spent several years analyzing metadata standards and collecting user requirements. PBCore v1.0, based in large part on Dublin Core, was released in 2005, and since then, it has been widely adopted not only by broadcasters, but also by media archives as the preferred scheme for descriptive and technical metadata. During several years of dormancy, PBCore was maintained by a loyal group of users, but with the planning of the new American Archive project, CPB is once again supporting PBCore with a release of 2.0 scheduled by the end of 2010. Based on an expanding community of user institutions, PBCore is proving to be very valuable in meeting its original goal as a standard for rich media metadata that is extensible, scalable, flexible and easy to understand.

1.3 – August 2010

PBCore version 1.3 added a new top-level element, a new attribute of string values, and removed the previous requirement to describe one or more instantiations of any asset. Its new element, “pbcoreAssetType,” could be used to explicitly declare the asset’s broad business purpose, and its new attribute “source” could help clarify the text value of an element, much like the attribute “version” has done. PBCore v1.3 used 62 elements organized into 15 containers and 4 sub-containers.

1.2.1 – December 2008

PBCore version 1.2.1 was published to better accommodate the possibility that a media asset may have multiple instantiations with various technical attributes. A new container called “pbcoreEssenceTrack” contains all other new elements to express different attributes associated with multiple instantiations. PBCore v1.2.1 used 61 elements organized into 15 containers and 4 sub-containers.

1.1 – January 2007

PBCore Version 1.1 enhanced the binding of related metadata elements (such as Title and TitleType) into new, hierarchically-organized “Element Containers.” In that arrangement, each Element Container collects and houses associated “child” Elements that are thematically related. Basically, what was a “flat” arrangement of the 48 PBCore elements became a more “nested” structure of 53 elements, arranged in 15 containers and 3 sub-containers.

1.0 – April 2005

PBCore Version 1.0 defined 48 metadata elements which combined to describe a media asset or resource’s intellectual content, creation, creators, usage, permissions, constraints, use obligations, and its form or format in the physical or digital realm.

Use ‘pbcoreCollection’ to wrap any number of ‘pbcoreDescriptionDocument’ asset records for sharing or to express the structure of a collection of records.