As previously posted, CPB has hired WGBH, Digital Dawn and AVPS to further the development of PBCore. As an interim step towards PBCore 2.0, and to accomodate PBCore’s use in CPB’s American Archive Project, we are working on version 1.3, due out at the end of July.
Attached to this post you’ll find a document that we’re working from as we consider changes to PBCore. It’s a grid which includes Digital Dawn’s requirements for changes to PBCore in the first column, and WGBH’s plan to address the changes in either 1.3 or 2.0 in the remaining columns. We’ve also incorporated comments from Dave Rice at AVPS – thanks Dave!
Many of the changes have to do with documentation and best practice examples… more so than schema changes. If you have an example best practice or suggestions for documentation clarity please pass them on to the WGBH team by commenting here on the PBCore blog or via our contact form! In addition, keep your change requests for 2.0 coming! We’ll be posting more about requests received so far in the coming days – requests submitted by July 25th will be considered for PBCore 2.0 (due to be published in early November).
After reading the recommendations and comments on the PBCoreRequirementsGrid, I want to offer a couple of notes:
1) On the topic of Linked Data, the idea is you could have a Contributor named “Hughes, Langston,” or “Smith, John” where the common name may or may not be ambiguous or unique. But if you add an actual UID to the name, it would be unambiguous and machine-readable. The Linked Data way of doing this is to include a URI for the person. This makes it possible to traverse the universe of objects containing this URI, and it links our PBCore object to that universe. We could optionally add URIs to place names, organizations, subjects, and relationships in the PBCore record. The way to allow this would be to add optional attributes to the PBCore schema, so you could include UIDs inside elements. I wouldn’t make it mandatory though, because many PBCore users might not be ready to go to the effort of adding UIDs like this. (On the other hand, I’m thinking about ways to automate the inclusion of UIDs in our cataloging tools and workflow. The payoff from doing this seems likely to be worth the effort.)
2) The recommendation of adding Profiles seems very important to me. For example, a PBCore record conforming to a COVE profile would be able to validate against COVE metadata requirements. The COVE metadata requirements include a character-count limit on Title and Description fields, and a specific COVE taxonomy. If I could feed COVE a PBCore record that COVE knows is COVE-compliant, I wouldn’t have to enter metadata into COVE by hand which is the current workflow. You could specify a Profile by adding a namespace attribute in the PBCore document root, and attributes inside the relevant elements. So COVE would need a schema to validate the document, but that’s easy. I’m guessing Public Media Publisher or whatever is coming down the pike could function in the same way. PBCore documents based on Profiles would remain valid and parse-able by applications that don’t care about Profiles. All we’d be doing is adding functionality for applications that do know about them…and make it easier for people like me at stations that need to feed the same content to different systems
Attributes would have to be allowed by the PBCore schema to make any of this possible. Then you could unambiguously identify a wide number of values, include URIs for elements like subject, contributor, and identifierSource, ease PBCore into the Linked Data universe, and enable the construction of usable (and machine-readable) profiles.
Respectfully,
Jack Brighton