Some thoughts on future directions of PBCore
For the last couple weeks, I've been thinking about some ways PBCore could changes to be easier to use and friendlier. Part of this was spurred by the PBCore 2.0 RFP, but also while I was trying to figure out how to teach PBCore to a workshop introducing XML at AMIA '09. This allowed me to take a step back from my use of PBCore to power digital archives and think about some bigger picture issues. I've been jotting my thoughts down elsewhere, but it would be more helpful to the community to record them here as well.The first two links are likely the most interesting and provoking because they offer some future directions for PBCore. I've tried to keep my ideas in line with current practice, rather than offering radically new idea (that are probably impossible to implement within PBCore). As I prefaced the first post with, my proposals focus primarily on the descriptive aspects of PBCore, which, in my opinion, is its most important aspect.
The third link offers something to think about, because it offers five different XML metadata schemas that could be used to describe video. I think it is interesting to examine other schemas to see how other communities approached (or avoided) similar problems. I wanted to keep my introductions brief, mainly to create some context for the structures that follow. As I suggest in that post, there is probably some fruitful work in doing detailed comparisons of the schema components.
- - 15 ways to improve PBCore - General thoughts about possible directions for PBCore.
- - Teaching PBCore, Questions and Notes - Reflections after teaching the PBCore workshop.
- - A comparison of metadata standards for media - example instances galore.
It's probably in the interest of this community to leave general comments and feedback on pbcoreresources.org (or, even make a post of your own..), but I naturally welcome comments on the posts themselves.
To be clear, the views expressed are my own, and do not reflect the views of my employer
Comments:
-
Chris,
It’s great to see your constructive thoughts.
I might dig back into my suggestions from a year ago and recall the clear need for better schema to support clip chapters, and audio channels.
But all would be solved if we had major entities with two desperate systems engaged in the enhancement of PBCore so support machine-readable interchange of data between them.
Like, say, ProTrack and COVE.
As it is, it seems we have a handful of relatively small initiatives using PBCore internally, without any attempt or strong need for interchange. I can only fear that the looseness (flexibility) of PBCore’s taxonomy and schema is resulting in each of these efforts building data sets that are human readable, but seriously incompatible for machine interchange.
To get attraction and a tight bond, we need two very strong opposing magnets.
Warm regards,
Bruce Jacobs
-
Bruce,
Great point—I’d also add that the participation of organizations (such as libraries and archives) that have been using, generating, and exposing metadata is perhaps even more important. For the right person, connecting ProTrack and COVE is (or should be) trivial, but developing a truly portable and reusable standard requires an additional (and more difficult) step.
That said, I think using COVE as an example “vendor” is very appropriate, because access applications like COVE end up covering a wide swath of use cases (discovery, media workflow, playout, security + rights) across a variety of partners (producers, consumers, stations, enthusiasts, etc). Given the right support, COVE could have been the “killer app” PBCore has been lacking.
Chris
-
Thanks for pointing us to these posts Chris. I’m completely with you on the Teaching PBCore Questions - lack of attributes has been bothering me since day one. The advantages of XML are certainly not being utilized.
I appreciate the comparison to other schema. Interesting to note that EBUCore and NewsML include administrative metadata, which PBCore steers clear of. I don’t think this is necessarily a bad thing for PBCore to do—it shouldn’t try to be all things to all people. Actually, the fact that you can’t separate the technical metadata and the descriptive metadata in PBCore is a problem in some cases. Some people would like to use PBCore specifically for technical metadata, and use other standards like DC and MODS for descriptive. That’s an option I’d like to see in PBCore 2.0.
Kara
-
Kara,
In order to satisfactorily separate descriptive and technical metadata, I think PBCore would need to assert relationships at the instantiation level (which would be a very good thing..), in addition to the intellectual level. On my archives project at WGBH, we’ve actually been faking this by creating PBCore documents for each asset, and then working some magic on the way out to reassemble a “proper” document.
Also, your point about technical metadata inspired me to dive into the technical metadata schemas I know about—see http://authoritativeopinion.com/blog/2009/11/28/metadata-standards-continued-technical-metadata/
Chris
Write a comment: