WNET/Thirteen releases its implementation of a PBCore Cataloging Tool
WNET/Thirteen hereby releases the software of its PBCore Repository Project under the GPLv3 license (http://www.gnu.org/licenses/gpl-3.0.txt). The PBCore Record Repository is an online database tool built on Ruby on Rails, Sphinx search, and MYSQL that was created at WNET/Thirteen to facilitate the import, export, search, creation and modification of PBCore records according to the PBCore 1.2.1 standard (http://www.pbcore.org/PBCore/PBCoreXMLSchema.html). For testing and evaluation a public installed version of the application can be found at http://pbcore.vermicel.li (for administrative testing log in as username=admin and password=secret). This work employs PBCore. The PBCore (Public Broadcasting Metadata Dictionary) was created by the public broadcasting community in the United States of America for use by public broadcasters and others. Initial development funding for PBCore was provided by the Corporation for Public Broadcasting. The PBCore is built on the foundation of the Dublin Core (ISO 15836), an international standard for resource discovery (http://dublincore.org), and has been reviewed by the Dublin Core Metadata Initiative Usage Board. Copyright: 2005, Corporation for Public Broadcasting. Further technical documentation can be found here http://git.mlcastle.net/?p=pbcore.git;a=blob;f=doc/README_FOR_APP;hb=HEAD and a current snapshot of the source code here http://git.mlcastle.net/?p=pbcore.git;a=snapshot;h=HEAD;sf=tgz. This tool is under development and feedback is appreciated. David Rice Digital Media Archivist WNET/ThirteenPBCore Genre Picklist from Hell
Let's be honest: The controlled vocabularies for pbcoreGenre suggested at pbcore.org lack relevance in many cases. I mean, "boat"? The main genre list suggested, "PBCore + Tribune Media Services Genre Categories (TiVo)," is mostly very good as far as it goes. But it doesn't go far enough.
And here's the problem: Because it's on the official PBCore website, it looks to many people like the Official PBCore Genre List. I've spoken with several PBCore users (speak up if you wish) who wanted to use certain genre terms not on the list, but didn't think it would be valid. It is valid, as long as you also declare the genreAuthorityUsed to identify the genre list.
This really matters when you want to exchange stuff between systems that speak PBCore, and you want that stuff to show up in the right places. By using a controlled vocabulary that is common to the systems exchanging the stuff, things work as intended. If I call something "boat" and you're expecting "marine," things fall apart. If I use "Horse" as in the suggested picklist, and your system wants to call it "Equestrian," we have a problem.
So what would move this forward? I'll suggest something: People should compile a genre list for a given PBCore user community (yes these really exist), and document it clearly for that community. Code it into applications (in drop-down lists for example) so everyone selects terms from the same genre list. Name that list, and you've got a valid new PBCore genreAuthorityUsed.
automating formatIdentifiers for digital assets
For the use of formatIdentifier, pbcore.org states "Best practice is to identify the media item (whether analog or digital) by means of a string or number corresponding to an established or formal identification system if one exists." This field holds such values as barcodes, unique tape labels, file paths, database generated unique identifiers, and other such data.
In addition to these types of data, I needed an identifier to track the use digital assets in Final Cut workflows and to identify when the digital archive is receiving the same exact file more than once.
In a Filemaker based PBCore staging database I added these scripts (assuming that formatLocation hold a usable filepath):
Perform AppleScript ["tell current record¶set cell \"formatIdentifier\" to do shell script (\"md5 -q '"& PBCoreInstantiation::formatLocation &"'\")¶end tell"]
Set Field [formatIdentifierSource; "md5"]
and
Perform AppleScript ["tell current record¶set cell \"formatIdentifier\" to do shell script (\"echo `tail -c 50 '"& PBCoreInstantiation::formatLocation&"' | head -c 41`\")¶end tell"]
Set Field [formatIdentifierSource; "com.apple.finalcutstudio.media.uuid"]
Note: The resulting formatIdentifier here must be evaluated to see if it conforms to the Final Cut UUID standard (ex. 13EBEE4A-FB65-4AF4-97F3-8B02A04A0A71), else you're just getting random bits from the end of the file. Possibly using this method you could also determine that Final Cut is the creatingApplicationUsed if you're using PREMIS as well. Let me know if you have a more efficient or alternative ways to extract Final Cut's internal UUIDs from media files. /
As described above, the steps must be placed in the proper Filemaker script context to generate a new formatIdentifier record that relates to an instantiation record before running, but the result is formatIdentifiers that contain an md5 checksum and, if appropriate, the Final Cut UUID. If the resulting PBCore records contain records that have equal formatIdentifiers where formatIdentiferSource equals "md5", then you have redundant multiple media copies. The Final Cut UUID is assigned to most files that Final Cut generates either through capturing or exporting. This value is usually also stored in the Final Cut project binary (the .fcp file) and can be used to build relation records between source material, the Final Cut project itself, and (occasionally) the exported material.
Shot Descriptions - standard or add-on for PBCore?
Anyone have a recommended standard for describing the shots themselves (within the programs)? I use PBCore to describe content, but need to describe it in better and exhaustive detail (i.e. wide shot, exterior, night.) Does PBCore allow for this, is there a controlled vocabulary in place (or available from another source that you can recommend) to describe footage in this way?
Thanks for the help.
Story-related images, WTF?
Let's say you have a radio news web page, with a title, text description, byline, date, and audio archive. All straightforward to encode in PBCore. But what if you have a related image, as is often the case? (Example: http://will.illinois.edu/news/story/fedrb-f/, or all over npr.org)
We could make a separate PBCore record for the image, then include <pbcoreRelation> element containers to connect the image with the radio news story with "Is Part Of" and "Has Part" values. That means we'd be spending lots of time cataloging images. That might be a good thing, but is it the only PBCore way of doing things?