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

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.

Linda Tadic gave an excellent overview of how metadata organizes information in order to catalog objects, and Dave Rice followed with specific examples of use cases for groups using PBCore, like WNYC Radio Archives, 25 years of Fresh Air programs at WHYY, and the Dance Heritage Collection collaborative catalog. Then Chris Beer spoke about PBCore update activities and the website.

Much of the material was technical and descriptive, very concrete for video users. But it seemed to be just what the attendees were looking for – they took copious notes, and even though the workshop was scheduled near the end of a long day, no one left – everyone stayed until the session was over, and many followed us into the hallway asking questions and wanting more.

Needless to say, it was quite exciting to have a disparate group of web producers and videophiles eager to learn about something as geeky as metadata.   We were very surprised, but totally gratified.

A few weeks later at the AMIA conference in Philadelphia, there were several sessions on metadata and PBCore, also full. Now I would expect that a gathering of moving image archivists should be interested in metadata, but this year it was more than casual – it was one of the central themes, and during the entire week there was continuous conversation about PBCore and other descriptive metadata standards.

It struck me that the light bulb has finally gone off — not just archivists, but video producers and television and radio broadcasters are finally realizing the importance of S & M (standards and metadata!) and that good metadata is a MUST for log-term access to their digital productions.

And they have discovered PBCore as both a useful and a usable tool to describe and help manage their precious creations.   All the more reason to finalize the improvements in the schema and create new training aids, to keep up the forward momentum.

Nan Rubin

Open Video, October 1-2, New York City
An Introduction to PBCore 2.0: Metadata for Public Broadcasters
PBCore has served the Public Media community as a metadata schema for describing media since 2005. With a new round of funding from the Corporation for Public Broadcasting, WGBH Boston is working on PBCore 2.0 – an updated version which will increase its flexibility as a schema and therefore its applicability to diverse user scenarios. In addition, a new web site with updated documentation is set to launch. Come learn about PBCore: how it is evolving, how it is applied, and how it can benefit your workflow and interoperability as a video content producer or consumer.

IASA/AMIA, Nov 2-6, Philadelphia
Coming Attraction: PBCore 2.0
There are a number of metadata standards being used by the library and archival community. However few are adequate, and easy for describing media collections. PBCore is a metadata standard that was developed specifically to describe media. Many in the moving image archival community have begun to utilize the standard. After 2 years of a development hiatus, a new initiative has launched to continue development of the standard to bring it to PBCore 2.0. This session will give an overview of PBCore – why it is a good standard to use for media collections and the work to date to bring it to PBCore 2.0. It will demo and tour the new redesigned PBCore.org website highlighting changes, navigation, and the community input features. And finally there will be several use cases showing practical use of PBCore in real archive projects. The end will be a roundtable discussion to get more feedback from the AMIA/IASA community and take questions.

In addition, join the listserv to stay current on PBCore.

Finally, send us feedback about this site! We are still in the process of re-designing… what do you think? Comment here or help us out by answering our survey about metadata sites.

PBCore_2.0_Changes_100726.xls

We had a lot of repeat requests which is encouraging and has help us focus in on a few key changes needed for PBCore 2.0:

1. Collections – how to bundle or wrap multiple PBCore records into a collection or feed
3. Episodes/Chapters/Segmentation – how to use PBCore to represent complex records
4. Multiple Carriers – how to express one work across multiple carriers (e.g. one program that spans three tapes)
5. People and affiliations – how to increase PBCore’s capacity to store structured “people” data
6. Controlled vocabularies – many are outdated and need review. Also support linked data protocols by allowing references to UIDs or URLs.
7. Rights – how to make use of PBCore’s extension capabilities to express more complex rights metadata

Many of these issues point to the fact that PBCore 1.2 and 1.3 have not been fully documented on this site and new examples are needed.

We hope to remedy this and include 2.0 documentation as we continue to re-vamp the site this fall. If you have any comments or suggestions on how to address the issues outlined here or in the spreadsheet, please pass them along! Comment on this post or email pbcoreinfo@wgbh.org.