Metadata in the Avalon Media System, present and future
Julie Hardesty at Indiana University (IU) and Karen Miller at Northwestern University (NU) serve as metadata specialists on the Avalon team, working to develop requirements and standards for metadata in the Avalon Media System. In this interview Julie shares their insight into the current status of metadata in Avalon along with future considerations.
What types of metadata may be created for items in the Avalon Media System?
In Avalon it is possible to convey descriptive, structural, and content information about items. Descriptive metadata lets you know things about an Avalon item such as the title, creator, date when the item was created or issued, publisher, subject or genre information, and whether it’s a moving image or an audio item – information that will help you identify and differentiate that Avalon item from another Avalon item.
Structural metadata deals with the digitized files that make up the digitized item (.mp3, .mp4, .wav, .mov, etc.). For example, if there are multiple audio files that combine together to create a single recording of the IU Symphony Orchestra from October 20, 1982, structural metadata is going to tell you which files are part of that Avalon item and how they should be ordered to correctly play back the symphony performance from start to finish.
Content metadata reflects table of contents/track-listing/chapter list information, so the order of things is important but it also identifies the content on the digitized files. It’s possible that content metadata overlaps with structural metadata (a single track from a track list could very well be split across 2 or more digitized files) so content and structural metadata have to be able to work together pretty tightly.
Why did you decide on MODS for descriptive metadata over other schemas?
We decided on MODS because IU and NU both already have a majority of our collections described at some level in our library catalogs. This means MARC data is abundant. It is possible to crosswalk existing MARC metadata into MODS, we have expertise in MODS (Karen Miller at NU is so the MOD-est of the MODS), and we can take MODS and express that descriptive info in Dublin Core or PBCore or any other metadata standard needed.
PBCore was a standard we considered for descriptive metadata, but with PBCore, there wasn’t always a good fit between our MARC info and the descriptive info that PBCore can track and having PBCore as the base for descriptive metadata also meant more difficult transformation work for us.
Which MODS terms are available in Avalon?
So we have MODS and then we have MODS in Avalon. What Avalon currently offers is a small set of what Karen and I want to have available. Right now we are limited to title, creator, and date info (which is required for any Avalon object) and then there is space for contributors, publishers, subjects, genres, a general description/abstract, and the type of resource (video or audio). These were easy to translate into MODS and seemed essential to be able to describe an Avalon item and differentiate it from other Avalon items at a basic level.
What new MODS terms would you like to add?
Right now, we don’t have a great way to detail publisher info, just a single field. It would be nice to distinguish between publisher name and publisher place because if you have one, you often have the other. Additionally, identifying roles for creators and contributors would make the descriptive info a lot more helpful, I think.
When can we expect new MODS terms to be added?
As we start producing interim releases (“dot” releases, like 3.1 and 3.2, etc.), my hope is to bring in additional descriptive fields with each “dot” release. Some of this is also being helped along by the needs of real places trying to make use of Avalon at IU and NU. Language and physical description (of the original item that was digitized) are hopefully going to be added with the next “dot” release, for example, because the IU Moving Image Archive needs that information along with our other fields to describe and differentiate their items at what they consider a basic level.
A metadata schema isn’t currently being used for structural metadata. How does this work?
We currently encase our structural metadata within Fedora’s system instead of starting with a standard like METS. To make an Avalon item, MODS metadata is stored as a datastream in the Fedora digital repository alongside the digitized files (mods.xml is right there with the audio.mp3, for example). The structure of the Avalon item (for example, 4 files that should be in a certain order for proper playback) is actually being handled by RELS-EXT (Relationships-External) in Fedora, relationship definitions defined for Fedora digital repository objects and expressed in RDF XML. So we’re taking advantage of what Fedora can do. This is related to our Agile development process in that it was quicker to use Fedora’s relationship definitions to get things started and functional for Avalon items structured with multiple files than to implement a METS structure that then required further programming to express this structure within Avalon.
How is Avalon currently dealing with content metadata?
Avalon is not dealing with content metadata in the current version (Avalon 3.0). METS currently seems to be the best option for implementing content metadata but I think we are open to hearing from our partners and potential users about what they need and how they’re interested in using this information. My experience with METS is that it can be easily overdone because EVERYTHING can go into a single METS file (structural and content information – even MODS can be wrapped inside METS) – it can turn into a giant beast that becomes hard to manage over time. I have some experience with this and know it can lead to logistical problems for updating METS information, something that I don’t want to see happen with Avalon.
So the team is exploring the best way to implement structural and content metadata. What are some of the contenders and considerations?
PBCore is a standard we keep looking at, thinking about, and then backing away from for different reasons at different times. It might be worth it to explore what PBCore can do for us in comparison to METS. As a standard, it allows for descriptive, technical, and structural/content metadata on multiple types of time-based media, but not quite the way we want to use it for our library catalog-sourced data and not quite the way we can build on over time. PBCore is all about the instantiations (all the different versions of a time-based item), which is where the structural/content metadata is located. In our previous releases, we weren’t dealing with any of that data, only descriptive metadata.
I think other factors affecting our decisions about PBCore are share-ability (who among our partners and users can easily make use of PBCore and how do they make use of it – please let us know!) and support (does PBCore have a solid structure for long-term support and maintenance as a metadata standard). Again, it would be great to receive feedback and thoughts from partners and others who have tried Avalon or are considering using Avalon to know if a certain direction is going to make or break things for you.
Encasing our structural metadata within Fedora’s system is familiar but also requires a lot more programming overhead. Maybe it doesn’t matter what we do for Avalon’s functional purposes as long as we bake in the ability to expose content and structural metadata in a standard format for external uses. It’s a hurdle regardless of the metadata standard we choose and how we implement the functionality in Avalon, but I think if anyone can make it work, it’s the Avalon team!
We encourage you to share your thoughts with Julie Hardesty at jlhardes@iu.edu. To discuss these topics with the larger Avalon community, join our discussion list on the connect page.
Contact Us | Facebook | Twitter | Listserv | RSS