An event for the ages:
PBCore Cataloging Workshop
A day of cataloging exercises and case studies
Wednesday, November 16th, 9 a.m. to 5 p.m.
At the Association of Moving Image Archivists Annual Conference, Austin, Texas
Find out if PBCore is a good data structure for your audiovisual assets. With PBCore experts, dig into the PBCore 2.0 schema and meet a range of tools; learn mandatory, suggested, and recommended elements, picklists and relationships; and explore workflows for handling intellectual content and instantiations. Gain a solid grasp of why and how PBCore is useful for handling analog and digital audiovisual objects.
The workshop will be held at The Harry Ransom Center, The University of Texas at Austin
I guess I know just enough about RDF to be dangerous. It may be that I am not plugging the namespace information in correctly, but all my attempts to wrap a PBCore XML record in RDF have failed validation in the W3C validation tool (http://www.w3.org/RDF/Validator/). I would really love and adore an example of a valid PBCore record in RDF.
Dave Rice, with support of the Dance Heritage Coalition’s Secure Media Network managed by Bay Area Video Coalition, has created a PBCore 1.3 to 2.0 XSL translator tool. For valid input PBCore 1.3 records, the tool generates a valid 2.0 records as the output.
This process revealed some difficult mapping challenges that have yet to be fully resolved. The main issue is the move away from elements like genreAuthorityUsed to the @source attribute. At first glance, it makes sense that genreAuthorityUsed would become pbcoreGenre source=“authority” in PBCore 2.0. But wait, there was an @source attribute for genreAuthorityUsed! So if the value of genreAuthorityUsed is now 2.0 pbcoreGenre source=“authority”, what happens to 1.3 genreAuthorityUsed source=“name”? It’s lost!
Given that the definition of @source in PBCore 2.0 is “Attribute source provides the name of the authority used to declare data value of the element,” for this and a few other elements, it appears to be impossible to create a sematically lossless mapping.
We have posted the translator to github for public review. You will see in the header comments of the XSL a number of issues that have come up in the mapping, including the genreAuthorityUsed problem. Issues have been identified for mapping 1.3 titleType, descriptionType, and subjectAuthorityUsed.
You can find the translator here: https://github.com/avpreserve/random-pbcore-metadata-translators/blob/master/13_to_Pbcore2.xsl
We would love to get feedback on this from the PBCore community!
If you haven’t been to http://pbcore.org lately you’re in for a good surprise. The site has been completely rebuilt, and contains up-to-date documentation, news, case studies, and most importantly, the complete PBCore 2.0 schema. There, I buried the lead: PBCore 2.0 has been officially released!
If I’ve learned one thing about the PBCore user community, it’s that we’re not satisfied with the current state of PBCore. We’ve used it enough to discover its strengths in describing AV assets and creating shareable metadata, but we keep running into its gaps and flaws. We’ve been pushing for a change process, and have argued for specific changes. Common threads have emerged right here on this site:
- A need for PBCore to support multi-part instantiations, e.g. when you have one complete work comprised of several reels or tapes or files.
- A need to express rights information related to a specific Instantiation, instead of only the entire asset. For example, you might want to allow users to download an mpeg4 version of a film for personal use, but not grant the same kind of access to the actual film!
- Speaking of rights, formatting of the pbcoreRightsSummary element disallows inclusion of metadata from existing standards such as ORDL or Creative Commons, which seems odd to say the least. If you already have structured rights data, why not simply reuse it?
- A need to show relationships between Instantiations, like when you digitize a film to 10-bit uncompressed digital video, then encode an mpeg4 file from the 10-bit uncompressed file, it seems important to show that in the PBCore record.
- With pbcoreContributor, you can say that Harrison Ford is an Actor, but you can’t say what role he plays in the film.
- There’s no way to uniquely identify a person, subject term, location, or other value that might have an actual URI.
- The lack of attributes of any kind! Everything is elements and sub-elements, which seems inefficient and makes parsing more difficult.
- The lack of a valid way to identify clip information within an asset, for example where in the timeline a particular subject is discussed or a specific person appears.
- The lack of any way to bundle multiple PBCore XML records together in a feed or collection, so you could export/import large groups of records between systems or use PBCore in RESTful web applications.
Well good news folks! PBCore 2.0 is on the way, and it solves all these issues.