Read our blog

Media managed through Avalon can be shared in many places. Embedding the Avalon player in Omeka pages or webpages are two great ways to extend the reach of publicly accessible content. 

Omeka

The IU Moving Image Archive (IU MIA) exhibit, World War II Propaganda Films and IU: Audiovisual Production, Circulation, and Education, combines the advantages of two open source technologies. Omeka provides the IU MIA with a superb exhibit interface and the ability to classify films by subject. Avalon provides media management capabilities and enduring access to these films. After setting up the Omeka site and transcoding their media into Avalon, IU Moving Image Archive staff installed the Omeka plugin for Avalon. The plugin was created by IU Library Technologies’ Will Cowan. With a one-time addition of a line of PHP code, the plugin generates the Avalon media player embedded in an iframe. IU MIA staff simply copied the PURLs of the films from Avalon into the plugin menu of the Omeka pages. The plugin also works for audio items and the player’s dimensions may be easily reduced. The installation file and instructions are available on Will Cowan’s GitHub page.

Websites

Content in Avalon can spice up library outreach blogs or be shared by users on their own blogs and websites. An iframe embed link is included with every item in Avalon. Located directly beneath the player, the link may be copied and pasted into the code of any webpage. 

Next steps

Sharing media itself is useful, but it is also important to provide contextual information. The Avalon team recently added a button for the embedded player that brings users back to a media item’s original page in Avalon. This gives users the option to learn about the item and continue exploring your collections. Look for this feature in our upcoming release, Avalon 3.2.

Screenshot of the embedded Avalon Media System player with new the “i” link back button

July was marked by several exciting achievements. After completing extensive testing of Avalon 3.1 during Sprint 55, the team released Avalon 3.1 to the community. Northwestern University successfully implemented the new release on their production server, and Indiana updated their pilot server as well. The following sprint had the highest velocity to date. For those interested in our statistics, the team earned a total of 96 story points! 

Among the many completed stories are the following key improvements:

• We found that by increasing users’ thread limits, item failures during batch ingest are eliminated. The puppet installation script was updated to reflect this as well as manual installation documentation for configuring Matterhorn.
• We also designed the MODS mapping for several descriptive metadata fields, including language, original physical description, related item, and terms of use.
• The embedded Avalon media player now includes a button that links to the original item page in Avalon.
• We’ve also added the ability to navigate to subdirectories in the Avalon drop box, by using the browse-everything gem.
• We upgraded Avalon to Hydra 7 and its new gems. We will continue testing the upgrades in Avalon and making style improvements to the interface.

Learn the details of each story and view our Sprint Demonstration recordings below:

Sprint 55 – July 11, 2014 Demo Recording

• VOV-2858 - I want to know what the deal is with batches failing so regularly
• VOV-2761 - I want to understand what's in 3.1 and how to configure it
• VOV-2758 - I want to deploy a high-quality 3.1 release - continuing
• VOV-2769 - NU production go live by July 3

Sprint 56 – July 25, 2014 Demo Recording

• VOV-2881 - I want to test 3.1 on NU Prod (and IU Pilot?)
• VOV-2758 - I want to deploy a high-quality 3.1 release
• VOV-2858 - I want to know what the deal is with batches failing so regularly
• VOV-2884 - I want to make sure all new fields to fill out basic info for an item have MODS mapping defined
• VOV-2810 - When viewing embedded Avalon content, I want to link back to the item in Avalon
• VOV-2796 - I want the Avalon dropbox to allow navigation to sub-directories to look for media files
• VOV-2887 - I want to know how bulk actions should look and behave
• VOV-2849 - I want my batches to complete without bogus failures
• VOV-2690 - I want to upgrade to the latest Hydra components

See Release 3.1 in action and learn about the new features by watching our video demonstration:

For more information on 3.1, please visit the What's New in Avalon 3.1 wiki page.

Live from Northwestern University, please join us in welcoming the new Repository | audio + video! Northwestern’s media repository currently features two publicly accessible collections: Northwestern University Football Films and the Robert Marcellus Master Class Audio Archives. The team at Northwestern University tailored the product to meet their unique needs. While the NU branding bars and colors may be the most striking change, the team also made some behind-the-scenes changes, including the integration of their Handle System for item identification and additional permissions for collection editors. 

Check out Northwestern University’s Repository | audio + video or watch the Sprint 55 recording for a tour of Repository | audio + video from the perspective of a Northwestern University collection manager (see section [Demo] VOV-2769 - NU production go live by July 3).

We’re pleased to announce the release of Avalon 3.1. The major goal for our first dot release is to pave the way for production implementations of the Avalon Media System at Northwestern University and Indiana University, the Avalon software development partners. We’ve achieved production at Northwestern University and are looking forward to taking this next step at Indiana University.

Release 3.1 adds the following capabilities:

• Use LDAP groups to restrict item accessibility
• Change a thumbnail after the master file is gone
• Add a previously existing PURL or Handle to an Avalon object, in place of the Avalon-generated permalink
• Ingest previously transcoded files attached from the dropbox via “skip transcoding”
• Public Avalon items produce more meaningful results in search engines such as Google
• Improvements to error messages when batch ingest fails due to manifest file problems
• Numerous bug fixes involving thumbnails, dropbox, batch manifest files, and more

For more details on each of these new features, visit the What’s New in Avalon 3.1 wiki page. 

We welcome you to try out Avalon 3.1 on our public test server before installation. Installation options include virtual machine image, manual installation, and source code installation. More information on all available options is found the Download page.

Please share your feedback on release 3.1 via the Avalon discussion list, which may be joined through the Connect page.

The Avalon team has been busy balancing improvements, testing the Avalon 3.1 source code, and eliminating bugs in preparation for our next release. Avalon html pages have been updated with search engine optimization metadata and microdata to increase the clarity and usefulness of information provided in Google search results about Avalon media items. We’ve also updated the Avalon Collections Guide wiki page to reflect the new features of our upcoming release. Our major tasks for the next sprint involve testing release candidate 3.1 and fixing any bugs we find. 

Sprint 54 – June 27, 2014 Demo Recording

• VOV-2755 - I want my public Avalon items to show up cheerfully in search engines such as Google
• VOV-2758 - I want to deploy a high-quality 3.1 release
• VOV-2761 - I want to understand what's in 3.1 and how to configure it
• VOV-2820 - I want to have up-to-date collection management documentation for 3.1
• VOV-2810 - When viewing embedded Avalon content, I want to link back to the item in Avalon

In Sprint 53, the Avalon team completed work on LDAP-based access control and made significant improvements to the error messages generated by the batch ingest process. We’re working to strengthen the information provided about Avalon media items in Google search results with Schema.org and Google Webmaster Tools serving as our main resources in this process. 

To learn about all of Avalon 3.1’s upcoming features in advance of the release, check out the What’s New in Avalon 3.1 wiki page. 

Sprint 53 – June 13, 2014 Demo Recording

• VOV-1717 - I want to restrict item accessibility to members of one or more dynamic LDAP groups
• VOV-2757 - I want helpful error emails when my batch fails due to manifest file problems
• VOV-2755 - I want my public Avalon items to show up cheerfully in search engines such as Google
• VOV-2758 - I want to deploy a high-quality 3.1 release
• VOV-2761 - I want to understand what's in 3.1 and how to configure it

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.

In our last sprint, the Avalon team continued its progress on a major feature of 3.1, allowing Avalon collection managers to use LDAP groups to provide access to content. With Avalon 3.1, content permissions may be assigned to user groups created within Avalon, to LTI courses, and to LDAP groups. Enabling LDAP groups requires a simple configuration. The organization of LDAP groups and use of LDAP active directories vary by institution, so we are exploring the most efficient method for Avalon to search for LDAP groups.

We’ve completed work on the option to bypass transcoding of media files attached through the Avalon dropbox. New tooltips were written to clarify the process of assigning pre-existing permalinks, setting thumbnail images, and creating section labels for media content with multiple segments. 

To ease the transition to Avalon at Indiana University from the current media service, we’re working closely with IU Libraries Media & Reserves Services and IU Libraries Moving Image Archive. We’re planning an ingest workflow for their current and future content and have translated the current service’s metadata fields to Avalon’s so that records can be transferred.

Sprint 52 – May 30, 2014 Demo Recording

• VOV-2661 - I want to use Skip Transcoding for files attached from the dropbox.
• VOV-1717 - I want to restrict item accessibility to members of one or more dynamic LDAP groups
• VOV-2727 - I want contextual help about permalinks in the file management page
• VOV-2463 - BUG: Dropbox directories with spaces break batch ingest
• VOV-2723 - [IU Prod] I want to know what an Avalon-based VSS interactive ingest workflow will look like at IU
• VOV-2696 - [IU Pilot] Implement LTI for Oncourse and Canvas

Since the release of Avalon 3.0, the team has focused on putting Avalon in production at Northwestern University as well as adding features needed for IU’s move to production. We expect to implement and release the latest features by the end of June as a minor release 3.1.

In our latest sprint we created the ability to assign a pre-existing persistent URL (PURL or Handle) to media that has been added to Avalon. We also developed a way for collection managers to choose or change a thumbnail image for a video even after the master file has been deleted or moved elsewhere. Using HLS to create thumbnails means that this image is made from the best available derivative rather than from the master file.

Now the Avalon team is working on the option to bypass (skip) transcoding for media files uploaded through the Avalon dropbox. This option may be used when a transcoded version of a file already exists and can be provided instead.

In 3.1, Avalon will be able to take advantage of LDAP groups to authorize access to users affiliated with campuses or departments or other LDAP-managed entities.

We have assessed the impact of upgrading to Hydra 7, Blacklight 4, Bootstrap 3, and Rails 4. The upgrades have been deferred to after our minor release due to the amount of user interface rework required, but the work will commence shortly. In addition to these dependency upgrades, our next major release is likely to include some of the following features:

• Bulk operations to enabling publishing, access changes, or deletion of multiple items simultaneously
• Ingest queue management, so high priority items can be processed quickly even if there is a long queue
• Automated metadata ingest from OPACs
• Additional descriptive and administrative metadata fields
• Time limits on access permissions

What are your thoughts on our progress, ideas, and goals? We’re looking forward to your comments on our mailing list, avalon-discuss-l@list.indiana.edu. Our mailing list is also the place for our partners to share ideas and issues with existing Avalon pilots and implementations. 

Sprints for Avalon 3.0:

Sprint 49 - April 18, 2014 Demo Recording

• VOV-2396 - I want to install R3 
• VOV-2427 - I want have technical documentation for R3
• VOV-2625 - I want to tryout R3 on the demo server
• VOV-2629 - [design only] I want to be able to set time limits on sharing Avalon items with individuals, groups and courses.
• VOV-2630 - I want manual instructions for how to set up Avalon with AMS
• VOV-2631 - I want to have a technology training refresh after R3

Sprint 50 – May 2, 2014 Demo Recording

• VOV-2625 - I want to try out R3 on the demo server 
• VOV-2630 - I want manual instructions for how to set up Avalon with AMS 
• VOV-2663 - I want to configure R3 features when I set up or upgrade Avalon 
• VOV-2664 - I want to use R3
• VOV-2660 - I want to add an previously existing PURL or Handle to an avalon object
• VOV-2633 - I want to configure dropbox privacy and access 

First Sprint for Avalon 3.1:

Sprint 51- May 16, 2014 Demo Recording 

• VOV-2660 - Add a previously existing PURL or Handle to an Avalon object 
• VOV-2659 - Change a thumbnail after the master file is gone 
• VOV-2661 - Skip Transcoding for files attached from the dropbox. 
• VOV-2690 - Upgrade to the latest Hydra components 
• VOV-2631 - I want to have a technology training refresh after R3 
• VOV-2695 - [IU Pilot] Implement PURLs
• VOV-2626 - [NU Prod] I want to test R3 on NU Production and identify problems 
• VOV-2628 - [NU Prod] I want to use Avalon with Blackboard and Canvas