Simply put, PBCore is a way to organize audiovisual content.

Public broadcasting communities in the United States originally developed PBCore so that producers and local stations could better share, manage and preserve their media. Since then, a growing number of moving image archives and media organizations outside of public broadcasting have also adopted PBCore to manage their audiovisual assets and collections.

Your organization can use PBCore as:

• A content standard for cataloging or describing audiovisual content
• A model for building custom databases/applications
• A guideline for identifying a set of vocabularies for describing audiovisual assets
• A data model for configurable collection management systems such as Omeka, Collective Access, etc.
• A guideline for creating inventory spreadsheets

PBCore was originally based on Dublin Core; so users of Dublin Core should feel comfortable with PBCore fairly quickly. However, PBCore offers a few additional features that make it especially useful for cataloging audiovisual collections. First, PBCore draws a sharp distinction between assets (abstract representations of the intellectual content of particular audiovisual productions) and instantiations (particular realizations of the Asset in physical or digital form). Second, PBCore offers a straightforward way to catalog the roles of the (potentially many) creators, contributors, and publishers involved in audiovisual production, as well as the relationships and distinctions between original and derivative materials used at different points in the production process. PBCore’s additional elements and guidelines provide flexible options for structuring and standardizing searchable descriptions of audiovisual-specific metadata.

PBCore is focused on providing a standardized way to describe audiovisual assets and related audiovisual material generally created within a broadcast environment. If you primarily need to describe manuscripts, photographs, or other materials that aren’t audiovisual or related to audiovisual content, PBCore is probably not the right choice for your project. While it is generally designed to manage descriptive and technical metadata, PBCore can be used alongside other standards to capture preservation, process, and additional technical metadata. To address more preservation needs, PBCore encourages the use of other standards through extensions and additions. For example, the American Archive of Public Broadcasting uses PBCore for descriptive and technical metadata, PREMIS for preservation metadata, and reVTMD for process history metadata.

Before getting started with PBCore, there are some questions you should ask yourself: What kind of information do I want to capture about my content? What kind of system do I want to capture it in? Do I already have a system for some of the content I want to capture or is there an existing system that I’d like to use? Will I have to build one from scratch? From there, familiarize yourself with the ways that PBCore structures and defines the data that you want to capture. Looking at the element definitions and the sample records is a good start. If you work with programmers or developers on ways to store your data, talk to them and figure out what their needs are and how PBCore can address them.
In practical terms, there are several scenarios where you can use PBCore:

1. You can build or customize your Media Asset Management (MAM) systems to conform to the PBCore standard. Almost all existing Digital Access Management (DAM) and MAM systems have database fields like Title, Subject, and Description, and many will have fields for Creators, Producers, and Contributors. Implementing PBCore in existing systems can be as simple as using existing fields, or using them more extensively. But many systems allow you to customize their fields to conform to a preferred standard. If you are building a system from standards-based tools like MySQL, establishing a foundation based on PBCore makes a lot of sense.
2. You can leave your existing systems as they are, and use PBCore as a standard for aggregating and exchanging metadata between systems. This is typically done by using export and import methods between databases, either as XML or CSV. In this case you would map existing fields in your various databases to the appropriate PBCore elements. Basically, PBCore provides a common language between systems, so you can build your import/export methods around it.
3. You can combine these approaches by leveraging your existing media databases, and building a new “master” catalog containing metadata from all your other systems. In this case, the master catalog can serve as a metadata repository from all your media systems without modifying them or impacting their operation.
4. You can use PBCore to capture and structure data in Excel to catalog a backlog of unidentified assets.
5. If you’re already using a cataloging standard that’s mainly for books or documents but you also need to capture information about audiovisual assets, you can incorporate PBCore as a standard to capture audiovisual metadata.
   
   Ultimately, PBCore can then serve as an exchange mechanism with other systems in public broadcasting such as the American Archive for Public Broadcasting. Many other systems and tools used in online media portals and trusted digital repositories are adopting PBCore as an exchange standard. With the ongoing development of PBCore and harmonization with EBUCore, there will be more opportunities to exchange metadata and content with these systems. By establishing a PBCore-based approach to managing your media assets, you will be ready to easily integrate with other systems.
   

PBCore was created by members of the broadcast and audiovisual archiving communities to meet the descriptive needs of audiovisual materials. If you don’t currently have a satisfactory, standardized way to store information about your content, PBCore can help ensure that you are capturing and keeping the data in a consistent and straightforward way. Stations throughout the public media system use different databases and tools to manage media and metadata such as traffic systems, playout servers, asset management systems, and tape logs. PBCore provides a way to aggregate and normalize metadata from those different systems to make everything findable, shareable, and reusable across different platforms. In many cases, stations also have many media assets for which little information exists. Think of tapes stored in desk drawers, or that USB hard drive full of digital media files. Many of these assets are valuable and deserve to be cataloged, and you may not know their full value until years later. A simple PBCore database can record and organize information about these assets and make them findable.

As an open standard, PBCore is free to use for anyone. For more information, see the Creative Commons licensing information on the Credits and License page.

Depending on your familiarity with metadata concepts and standards, adopting PBCore may require an investment of learning time. You might also need to develop tools, or customize your existing tools, to adopt PBCore into your media workflow. To build a PBCore-based media catalog, you can use inexpensive software like FileMaker, Access, or MySQL. You will very likely shorten any learning curve, and discover existing PBCore tools, by reaching out to the PBCore team at pbcoreinfo@wgbh.org

• Your investment of time will pay off as you develop your PBCore–based media catalog or metadata system.
• You’ll save time and resources by not developing your own schema.
• Your media assets will be findable, reusable, and shareable to whatever extent you want them to be. Your collection will be able to interoperate with a growing number of other media software systems and archives, including the American Archive of Public Broadcasting.
• You’ll have a digital media catalog you can repurpose for any intended use, from internal media asset management, discovery, and reuse, to stock footage sales and eCommerce, K-12 curriculum content, public website access, offline archives, and media preservation repositories.

Experience in the user community shows there are two common approaches to adopting PBCore. Which path you follow largely depends on your existing media asset management infrastructure.
You may have invested in various cataloging systems that already contain a great deal of metadata about your media assets, in which case you may choose to leverage those systems. This approach might save you development time, and may fit best into your existing media workflow (especially if you have skilled IT staff resources).
If you have no such systems, or if they are too inconsistent, siloed, or fragmented to leverage, you might choose to build or acquire a new PBCore-based media catalog system. You would then use this system as the center of your metadata creation, and export to other systems as needed.
Either approach results in a central repository of metadata you can search, export, and reuse for whatever purpose, including integrating other media systems.
The first step is to understand the PBCore elements. You should then evaluate your existing media software and asset management tools to determine how well they fit with the PBCore data model. Almost all such tools will “map” to basic PBCore elements like Title, Description, and Subject. Many systems have export features that allow you to set up a specific PBCore output format, either as XML or CSV files. This will enable you to reuse metadata from these systems instead of recreating it. As you may have many such systems, this can save you a great deal of time.
If you determine that leveraging your existing media systems will be too difficult or “messy,” your next step is to evaluate the existing PBCore tools. If one or more meets your needs, your path to adopting PBCore is straightforward. If you have unique needs based on your workflow or environment, you may choose to build or customize your own PBCore metadata repository using software like FileMaker or Access, or common databases and scripting languages like SQL and PHP.

Most media producers and organizations don’t think of themselves as catalogers or librarians. You don’t need to “adopt PBCore” or have a centralized system to begin building a media catalog. Using a simple spreadsheet, you can take the first step by recording titles, subjects, and descriptions for media assets. Here are some simple things you can do using desktop tools:

1. Record where to find the asset, whether it’s a tape on a shelf or a file on a hard drive or server. This is the most important piece of information that you have about each asset.
2. Give each media asset a unique identifier. To do this consistently, you should map out a naming convention for all types of assets.
3. Assign one or more of these elements to each media asset: Description, Subject, and Genre. These elements are already common to many metadata standards and software systems.
4. Record dates for production, broadcast, release, publication, and other relevant information for each asset.
5. Record the names of each person or organization who was a creator or contributor to the asset.
6. Record rights information about each asset. Determine who owns the copyright, any licensing of music, and any rights restrictions on access to or use of the asset.
7. Record technical details about the asset. This could include length, tape or digital file format, and any other important details like language, captioning, aspect ratio, etc. You can automate some of this work with MediaInfo, a program with the ability to create files for PBCore.
   
   If the above is all you have time and resources to do, you are already moving toward using PBCore. If and when you develop a more robust repository, the metadata you create in this way will fit right into it.

PBCore 2.1 is an incremental update to the PBCore 2.0 schema that provides clearer element definitions and more options to include detailed source information for metadata, while still being backwards compatible with PBCore 2.0. Changes for 2.1 include:

1. the option to include ‘@source, @ref, @version, @annotation’ information to all elements.
2. the addition of new optional attribute groups for the following elements:
   • for pbcoreTitle:
     • @titleTypeSource
     • @titleTypeRef
     • @titleTypeVersion
     • @titleTypeAnnotation
   • for pbcoreSubject:
     • @subjectTypeSource
     • @subjectTypeRef
     • @subjectTypeVersion
     • @subjectTypeAnnotation
   • for creator, contributor and publisher:
     • @affiliationSource
     • @affiliationRef
     • @affiliationVersion
     • @affiliationAnnotation
3. the addition of a @unitofmeasure attribute to the element essenceTrackBitDepth
4. the change of the element extensionAuthorityUsed from required to optional within the container extensionWrap
5. overall updated definitions and best practices for each element
   For more information on the process and rationale behind the development of PBCore 2.1, see the readme on the PBCore 2.1 GitHub repository.

Although the date for PBCore 3.0 has not yet been set, a roadmap for 3.0 is under discussion.

Reach out to us on the Contact page, leave an issue at the 2.1 GitHub repository, or email us at pbcoreinfo@wgbh.org. We’ll get back to you within two weeks with an answer (and maybe your question will end up here!).