So…lots going on in PBCoreland that hasn’t been reflected on pbcoreresources.org. I’ll get to that in another post. For the moment I want to mark something that is currently bugging me about PBCore 2.0: pbcoreAssetDate needs something to say what date formatting is being used. This is true for all other dates in a PBCore record.
I’m in the middle of building a PBCore export feature for WILL’s main website. This will allow exchange of pretty complete metadata with systems that can ingest PBCore, like the American Archive project (if it ever gets truly rolling) and the Popup Archive (which is rolling nicely). As I dive into the specifics, I want to return to and highlight those things about the PBCore 2.0 schema that remain…unfinished.
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!