PBCore_website

- 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.

Implementing PBCore Q: What are the steps to integrating PBCore into my current workflow and systems? A: 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.

Q: What if I don't have a a current workflow or systems? What does PBCore look like at the most basic level? A: 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.

Q: I'm already using PBCore! How is PBCore 2.1 different from PBCore 2.0? A: 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.

Q: When is version 3.0 coming? A: Although the date for PBCore 3.0 has not yet been set, a roadmap for 3.0 is under discussion.

Q: I have a question you haven't answered! What do I do? A: 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!)

Glossary

Asset: A single piece of content, such as a program, clip, or episode. One asset may exist in many different forms (for example, on DVD, on a U-matic tape in English, and on a VHS tape in French). If the content is the same, those would all be considered instantiations of the same asset.

Attribute: A structure used to provide more specific information about the data contained in an element. Within the context of XML, attributes are stored within the start tag of the element.

In this case, the element is pbcoreTitle, and the attribute titleType provides more information about the title.

Container: A container element in XML is a way to group other elements together. Container elements usually do not hold data themselves, but act as a bucket for sub-elements that do hold data. The container element is only relevant to PBCore users who are using the XML expression.

Digital Asset Management (DAM): An asset management system that either serves as a brand asset library or a system for storing and retrieving historical assets.

Elements: A way to describe and store data in a self-explanatory manner according to a structured vocabulary. This would appear as “Title: Lassie.” “Title” is the element, and “Lassie” is the value. Putting the information “Lassie” within a “pbcoreTitle” element tells anyone (or any machine) looking at the data that “Lassie” is the title of the asset. Attributes may be associated with any element, and provide even further detail about the data.

Instantiation: A particular realization of an asset that is embodied in physical or digital form, such as a tape, DVD, or digital file. One asset can have many instantiations, but generally, each instantiation holds the same intellectual content.

Media Asset Management (MAM): An asset management system that’s primarily a part of an audio or video workflow. MAM systems are primarily for audiovisual creators that allow them to put content in a central location so that editors can access it.

Metadata:

A set of data that describes and gives information about other data in a deliberate and structured fashion, allowing for discovery, identification, and preservation. Some examples include description (title, subject), technical information, or rights information. Metadata can include a wide variety of information, and different communities have different uses for metadata. Often there are different types of metadata needed for different purposes: structural metadata, technical metadata, and preservation metadata. PBCore elements include descriptive and technical metadata, and some people also use it for preservation metadata.

Schema: An XML schema provides the framework for structuring an XML document. The PBCore schema specifies how PBCore information should be written in XML so that people and machines can consistently understand the information contained in PBCore documents by referencing the schema.

XML (Extensible Markup Language): A markup language that defines a set of rules for encoding documents in a format that is readable by both humans and machines. It is defined by the W3C‘s XML 1.0 Specification and by several other related specifications.

XSD (XML Schema Definition): The document that defines an XML schema. It can be used to validate other XML documents to make sure that they are complying with the rules of the schema.