FAQs

PBCore User Guide Wiki

FAQs


1. What is PBCore?
2. What is PBCore not?
3. How can PBCore benefit my archive description and program goals?
4. How do I get started with PBCore?
5. Does it cost anything to adopt PBCore?
6. What kind of time, staff, or training do I need?
7. What is the expected return on time investment?
8. What are the steps to integrating PBCore into my current workflow and systems?
9. What if I don’t have a current workflow or systems? What does PBCore look like at the most basic level?
10. I’m already using PBCore!  How is PBCore 2.1 different from PBCore 2.0?
11. When is version 3.0 coming?
12. I have a question you haven’t answered! What do I do?

1. What is PBCore?

PBCore is a metadata schema designed for sound and moving images.

PBCore can be used as:

  • A guideline for cataloging or describing audiovisual content (as a content standard)
  • A model for building custom databases/applications
  • A guideline for identifying a set of vocabularies for fields describing av assets
  • A data model for a configurable collection management system (Omeka, Collective Access, etc.)
  • A guideline for creating inventory spreadsheets
  • An exchange (import or export) mechanism between applications

PBCore records can easily be shared, allowing information about media assets and collections to be exchanged between organizations and media systems.

Public Broadcasting in the United States developed PBCore so producers and local stations can better share, manage and preserve the media they produce.  Because it is so useful in describing media assets, a growing number of film archives and media organizations outside of public broadcasting have adopted PBCore to manage their audiovisual assets and collections.  

2. What is PBCore not?

Like any metadata standard, PBCore doesn’t cover all the information that you might want to store about any possible piece of content.  The PBCore schema is focused on providing a standardized way to describe audiovisual assets and related audiovisual material within a public broadcasting environment.   If what you mostly need to describe is manuscripts, photographs, books, or other material that’s not audiovisual or related to audiovisual content, PBCore is probably not the right choice.

PBCore is generally designed to be easily readable and understandable on a high level.  It does not go as in-depth into technical and process metadata as other standards, such as PREMIS or reVTMD, that are designed to capture that technical information for long-term management.  PBCore encourages the use of other standards through extensions and additions for structuring the kind of information that PBCore was not designed to provide.  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.  

3. How can PBCore benefit my archive description and program goals?

PBCore is a community standard XML schema. That means it was created by members of your community in the broadcast and audiovisual archiving communities to meet certain descriptive needs specifically for audiovisual materials.  If you don’t currently have a standardized way to store information about your content, or if you’re not happy with the kind of data that your current system lets you capture, PBCore can help make sure that you are capturing and keeping the data that’s important for audiovisual works in a consistent and easily understandable way. 

Stations throughout the public media system use different databases and tools to manage media and metadata: traffic systems, playout servers, asset management systems, tape logs, etc. PBCore provides a way to aggregate and normalize metadata from different systems to make everything findable, shareable, and reusable across different platforms.

In many cases, stations also have many media assets for which almost no 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 we 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.

4. How do I get started with PBCore?

Before getting started with PBCore, there are a couple questions you should ask yourself:

  1. What kind of information do I want to capture about my content?
  2. What kind of system do I want to capture it in?
  3. Do I already have a system that captures some of the content that I want, or will I have to build one from scratch?

From there, familiarizing yourself with the ways that PBCore structures and defines the data that you want to capture by 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, it’s a good idea to talk with them and figure out what their needs are and how PBCore best fits into that.

In practical terms, there are several scenarios for using PBCore:

  1. You can build or customize your media asset management system(s) to conform to the PBCore standard. Almost all existing 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 the PBCore schema makes a great deal 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. PBCore provides the lingua franca 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 (and desk drawers) without modifying them or impacting their operation.
  4. You can use PBCore as a model for how to capture and structure data in Excel when creating an inventory for a backlog of unidentified media assets.  
  5. If you’re an archive using a common standard such as DublinCore to catalog books or documents, you can incorporate PBCore into your workflow as a standard for capturing more detailed metadata about audiovisual assets.  

Ultimately, PBCore can then serve as an exchange mechanism with other systems in public broadcasting such as the American Archive. 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, opportunities to exchange metadata and content with these systems will grow. By establishing a PBCore-based approach to managing your media assets, you will be ready to easily integrate with other systems as you choose.

Here are some links to past blog posts and other resources that you might find helpful:

The PBCore team is always happy to answer questions through the Forum section of the website or by email directly at pbcoreinfo@wgbh.org.  

5. Does it cost anything to adopt PBCore?

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

6. What kind of time, staff, or training do I need?

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. You can build a PBCore-based media catalog using inexpensive software like File Maker, Access, or MySQL. You will very likely shorten any learning curve, and discover existing PBCore tools, by joining the PBCore community.

7. What is the expected return on time investment?

Your investment of time will pay off as you develop your PBCore–based media catalog or metadata system. Your media assets will be findable, reusable, and shareable to whatever extent you wish to make them. Your collection will be able to interoperate with a growing number of other media software systems and archives, including the American Archive. You will be able to publish media online with detailed metadata, including linked data, allowing users to discover assets that previously were hard to find or inaccessible. 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.

8. What are the steps to integrating PBCore into my current workflow and systems?

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 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 chose 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 allowing 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 chose to build or customize your own PBCore metadata repository using software like File Maker or Access, or common databases and scripting languages like SQL and PHP. You will also find useful open source software projects within the PBCore user community.

9. What if I don’t have a current workflow or systems?  What does PBCore look like at the most basic level?

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 recoding titles, subjects, and descriptions for media assets. Here are some simple things you can do using desktop tools:

  1. Give each media asset a unique identifier. To do this consistently, you should map out a naming convention for all types of assets. (We should provide some links to references on naming conventions.)
  2. Each media asset should be given one or more of these elements: Title, Description, Subject, and Genre. These elements are common to many, many metadata standards and software systems.
  3. Record dates for production, broadcast, release, publication, etc for each asset.
  4. Record the names of each person or organization who was a creator or contributor to the asset.
  5. Record information about the rights to the asset: Who owns the copyright, any licensing of music etc., and any rights restrictions on access to or use of the asset.
  6. Record technical details about the asset, including length, tape or digital file format, and any other important details like language, captioning, aspect ratio, etc.
  7. Most importantly: Record where to find the asset, whether it’s a tape on a shelf or a file on a hard drive or server.

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.

10. I’m already using PBCore!  How is PBCore 2.1 different from PBCore 2.0?

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
  1. the addition of a @unitofmeasure attribute to the element essenceTrackBitDepth
  2. the change of the element extensionAuthorityUsed from required to optional within the container extensionWrap
  3. 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.

11. When is version 3.0 coming?

Although the date for PBCore 3.0 has not yet been set, a roadmap for 3.0 will be available for discussion by the 2015 AMIA Conference on November 18-21 of this year.  

12. I have a question you haven’t answered!  What do I do?

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 on this FAQ!)