Read our blog

Understanding Avalon Roles and Permissions

 

The second release of Avalon will have collections-based roles and permissions. This post describes what we've designed in hopes of getting your comments. Does this make sense? Is it easy to see how you would map these to your organization?

Units, Collections and Items

 

First, some definitions.

 

A unit is a grouping of collections. Usually, a unit will map to an administrative unit.

 

A collection is a grouping of related items. 

 

An item is a bibliographic unit comprised of one or more audio or video files.

 

So it's a hierarchy--a strict hierarchy in that items can only belong to one collection, and a collection belongs to only one unit. If you need to make other kinds of groupings, such as for course reserves, special exhibits, or shared access restrictions, those will be accomplished through other mechanisms. The hierarchy defined above is for ownership and responsibility.

 

Both units and collections will show up in as facets for search and browse.

Roles and Permissions

 

We've designed the four roles below for the second release.

 

Administrator

Administrators will be a select few who have responsibility for providing an Avalon-based service. The administrators assign people to the manager role and maintain the list of units. Administrators are the only ones who can see and modify items in any collection.

 

Manager

Managers are those within a given unit who have overall accountability for the collection building within Avalon. Managers get to create collections and assign editor and depositor roles for those collections. They set the default access controls for items added to the collection, and they also step in when a published item needs revising or deleting.

 

Editor

Editors have supervisory responsibility for the collection building--the ingest and description process. They can assign depositor roles, change the name or description of the collection, and can modify the access controls for individual items in the collection.

 

Depositor

Depositors add media to the collection and describe it with metadata. They can publish items but not unpublish. They can only modify or delete unpublished items.

 

Permissions are also a hierarchy--an editor can do anything a depositor can do, and a manager can do anything editors and depositors do, and an administrator can do anything. Smaller organizations may not have a need for all four roles. But we hope that these four roles can be used to support even the largest, most complex institutions. 

 

An additional means of handling complexity would be to have multiple instances of Avalon running. If some collections are so self-contained that they don't need to share discovery services with other collections, running a separate instance may be the best way to handle the separation.

 

The chart below provides another view of the hierarchy of roles and their associated permissions.

 

 

Until we all start applying these roles, we won't know exactly what to recommend. Libraries tend to have few but large collections. Archives tend to have many more collections. How can we best organize our media collections to have them be both manageable and appropriately discoverable?

 

Questions? Suggestions? 

Tags:

Blog Categories:

Sprint 30 - July 12 Demo Recording

 

We've got roles! Managers, editors and depositors can now be assigned when a collection is created. Managers can create collections, assign access controls to their collections, and give Avalon users roles to allow them to add content to collections. Editors have very similar privileges except they cannot add anyone as a manager. Depositors can only add content to collections where they have that role and they cannot change the access control settings of the collection. The workflow for creating content has been altered slightly since the access control policy set at the collection level is copied to new items added to collection. Next week we will work on incorporating batches into the new collection model.

 

If you are going to be in Indianapolis for the Joint Conference on Digital Libraries, Jon Dunn will be doing a demonstration of Avalon version 1.0

 

Watch the full recording of this week's demo.

  • Creating items from Manage Content page (VoV 1721) - Phuong (0:00:00)
  • Roles enforcement (manager, editor, depositor) (VoV 1685) - Phuong (0:10:55)
  • Creating collections and assign roles (VoV 1683) - Phuong (0:19:26)
  • Video Link Bug Fix & Documented  (VoV 1679) - Michael (0:30:59)
  • Refinement of MODS to MARC crosswalk (VoV 1760) - Karen/Julie (0:41:12)
  • Review of Sprint Stories – Team led by Steve (0:48:10)

You can also watch the demos for past Sprints or learn more about our development process.

Blog Categories:

Sprint 29 - June 29, 2013

 

This week, the Avalon team spent a lot of time thinking about how to create collections without calling them collections! The team was able to almost complete backend modeling and testing; user interface will be the focus for the next sprint. Work was also completed on the crosswalk from the MODS fields that will be included in Avalon to MARC.  

 

We have a few team members up in Canada for Open Repositories 2013, so if you have any questions or want a quick demo just look for Jon Dunn, Claire Stewart or Adam Hallett!

 

Watch the full recording of this week's demo. 

  • MARC Field mapped to Avalon MODS fields (VoV 1641) - Andrea (0:00:00)

  • Video Link Bug Fix & Documented  (VoV 1679) - Michael K (0:05:26)

  • Creating and Managing Collections (VoV 1584/VoV 1586) - Chris/Phuong/Adam (0:11:43)

  • Review of Sprint Stories – Team led by Steve (0:40:01)

You can also watch the demos for past Sprints or learn more about our development process.

 

Get to Know the Avalon Team: Julie Rudder

 

In our series "Get to Know the Avalon Team," we're providing a closer look at the individuals who are working each day to develop the Avalon Media System.

Julie Rudder

Julie is one of two product owners for the Avalon Media System project. She works at Northwestern University Library and for the past five years has been helping faculty and graduate students incorporate digital media into teaching and research. Julie has experience in media streaming technologies and user facing support for use of media in the teaching and learning environment.

 

Can you talk a bit about your role in the project?

I am a product owner on the Northwestern side. In collaboration with Mark Notess from Indiana, I spend time trying to understand and communicate the needs Avalon users. Together, we wrangle the project priorities and end user needs while trying to decide what needs to be worked on and when. This work gets translated into user stories and organized into two-week cycles (sprints) of development.  

 

What is a typical work week like for you?

I spend a lot of time chatting with my counterpart, Mark Notess. It's important for us to be in sync with each other about what a story means and what it should look like. One thing I've learned through being a product owner is that availability is key.  Being available to team members to answer questions or think through issues very quickly helps us all stay on track and get work done in the two-week cycle. My role at Northwestern is Digital Initiatives Project Manager, so when I'm not working on Avalon, I'm working on other repository related projects.  

 

What apps/software/gadgets can't you live without?

I love Google Reader so I'm going to shed a few tears in July when it goes away.  Oh, and Netflix.

 

When you’re not working, what can you be found doing? 

I am generally happiest near the ocean, shelling or fishing. However in Evanston/Chicago I settle for the lake.  In cold weather, I turn to karaoke.  I am also involved in the art community in Chicago – currently on my plate is a show I'm curating at Hyde Park Art Center called Light and the Unseen.

 

Sprint 28 - June 14 Demo Recording

 

After last week's venture into exploring administrative units, this week the team focused on how collections can be employed by Avalon.  Administrative units can now create and manage collections of items. This will be an easy way for collection managers to add content to a specific collection, and our metadata specialists spent a lot of time thinking of how those relationships would be captured in each MODS record. We are also happy to report that both IU and NU's pilot systems are up and running! 

 

Watch the full recording of this week's demo. 

  • NU Pilot Status (VoV 1582) - Michael (0:00:00)
  • IU Pilot Status (VoV 1576) - Phuong (0:04:23)
  • Collections (VoV 1584) - Adam (0:09:33)
  • Collections and Units metadata fields (VoV 1586) - Julie H (0:34:14)
  • Review of Sprint Stories – Team led by Steve (0:49:21)

You can also watch the demos for past Sprints or learn more about our development process.

Blog Categories:

How Avalon differs from YouTube or a DAMS

 

(Last week we noticed that the Duke Digital Media Community featured Avalon in a blog post. Though they don't plan to implement Avalon at this time, we were very happy that they took the time to write about how they made this decision. Since our response might help other potential adopters of Avalon, we wanted to post it on our site.)

 

The Avalon Team is happy to see you take notice of our work! You are quite right that we are not targeting the YouTube-style end-user upload use cases, and Kaltura-killing is not on our to-do list. Nor are we trying to compete with MAM/DAM systems, where the focus is on managing content for internal use by media-generating organizations.

 

The needs we are squarely focusing on are those of libraries and archives, whose needs are not well met by any of the open source solutions available today. Neither are they well met by more than one or two expensive commercial systems. It has been a major activity of our work to explain to IT organizations why library and archive needs are not addressed by the kinds of media solutions initially adopted by campuses. In what ways are these needs not well met?

  • Metadata for the long haul. Although we are planning to rework our content ingest process to provide a better manual workflow, part of the reason all the steps are there is that library content, unlike the latest video from a cell phone, needs to be discoverable and accessible for a long time. Most course lectures and assignments tend to be ephemeral in nature rather than needing to be reliably found and viewed ten years hence. Of course some user-generated content does merit long-term preservation and access, but when it does, the content ends up having metadata requirements similar to any other curated library content.
  • Metadata for navigation. Most of the generic streaming media players simply provide a scrubber for navigation, on the assumption that most content is short. This doesn't work well for longer items such as operas, ballets, plays, or feature films. Adding structural metadata for chapters or tracks helps considerably. 
  • Flexible access control. Academic libraries and archives provide content under a wide variety of access control schemes. Rights differ across materials. Rationale and risk assessments differ across institutions. 
  • Security. Most streaming media systems either have no security or security by obscurity. Avalon is being designed to support delivery of highly sensitive content, whether for reasons of intellectual property protection, cultural sensitivity, human subjects protection, or other privacy concerns.
  • Integration. Avalon aims to integrate with pre-exisiting digital object repositories (such as Duraspace's Fedora) and enterprise media servers (such as Adobe's). Although many systems do integrate with institutional authentication and authorization, other integrations, such as with library catalogs for automatic import of descriptive metadata, or support for course reserves, are found only in systems that grow up within library environments.

So these are some of the distinctive needs Avalon aims to address with a freely available open source system. That said, we know Avalon will be used for scenarios beyond those we are intentionally addressing, and Avalon will likely be useful in ways we do not currently imagine. The Duke evaluation raises some good points and also identifies information gaps we can address here.

  1. The manual upload sequence of pages is indeed clunky, though we find people are able to be successful with it. We are planning to revise it, with the aim of making simple things simple and hiding optional complexity. But it is also worth mentioning that we expect most Avalon content will not be uploaded manually. We have a batch upload capability we expect to be the primary means of adding content: collection managers will put the master (or mezzanine) files on the server, along with a descriptive spreadsheet. Avalon then automatically ingests and processes the items and can even auto-publish them. Of course, this feature is more helpful for libraries and archives than for an individual submitting an assignment or example.
  2. Many institutions, like Duke, are looking for hosted solutions. For that reason, we are being careful to avoid licensing encumbrances (such as GPL) that would deter third-parties from picking up Avalon and offering it as a service. We expect one or more third-party providers to provide application hosting and related services, but it's a little early to start recruiting them.
  3. Player embedding is on our list of development priorities for early next year.
  4. Regarding Shibboleth, Avalon uses a Ruby gem called OmniAuth for authentication, and therefore supports several dozen authentication strategies with a minimum of implementation and configuration required to set them up. The difference between the default "identity" strategy and full integration with Northwestern's LDAP directory, for example, consists of 8 lines of code and a 10-line configuration file. IU's CAS integration is slightly longer at 23 lines of code and 10 lines of configuration, but only because it has to do a secondary LDAP email lookup after login. There is a third party, well-documented Shibboleth strategy available for OmniAuth, and it looks just as simple to configure as the ones mentioned above, with the addition of one stanza of Apache auth configuration.
  5. Thanks for pointing out we missed listing wmv in our supported formats. We’ve now updated that document to be current. We use HTTP live streaming to support iOS devices.
  6. We haven't yet tried or prioritized Wowza integration.
  7. The Engage player can be slow to start up. For this and other reasons we are investigating switching to mediaelement.js as our player of choice.
  8. The test site upload limit is due to disk space on the test server. We have been testing the system with files 50GB and larger, though not, of course, through the web browser. That's what the Avalon dropbox is for.
  9. We are currently implementing "collections", which will provide something equivalent for "my media", enabling collection managers to view their own collections (and preventing them from modifying collections for which they do not have editing privileges. Even in the existing system, "collection" is a facet you can filter on.

Finally, we’d like to point out that we have only recently release version 1.0 of Avalon. We have releases scheduled roughly every three months, so we are early in the development process and welcome input and evaluation such as this as Avalon makes progress.

 

Thanks again for the helpful review!

 

The Avalon Team

Blog Categories:

Sprint 27 - May 31 Demo Recording

 

This week the team worked on adding new functionality to Avalon. We introduced the concept of units to Avalon Media System. The term "unit" refers to an Administrative Unit, which can be made up of many collections and items. We also added some snazzy auto complete features to select unit managers. Besides units, more investigation of the mediaelement.js player occurred during this sprint. IU and NU spent some time getting their pilot systems set up. We're just about ready to see what Avalon 1.0 can really do! 

 

  • MediaElement Player (VoV 1583/VoV 1642) - Phuong (0:00:00)
  • IU Pilot Status (VoV 1576) - Chris (0:13:39)
  • NU Pilot Status (VoV 1582)/Puppet Clusters (VoV 1588) - Michael (0:18:15)
  • Units (VoV 1585) - Adam (0:23:06)
  • Review of Sprint Stories – Team led by Stefan (0:40:52)

You can see the demos for past Sprints here or learn more about our development process here.

Blog Categories:

Version 1.0 Webinar Recording Available

 

On Wednesday, May 29, the Avalon team hosted a community webinar. With around 50 participants and no technical difficulties, we consider it a smashing success! Thanks to all who joined us. 

 

If you missed the webinar, you can now watch the complete recording or view our slides.  

 

 

We would also appreciate it if you would take our brief survey. We're trying to learn about the community's plans and current practices to help shape future releases of the Avalon Media System. 

 

Blog Categories:

Sprint 26 - May 17 Demo Recording

 

After releasing Avalon 1.0, the team spent some time cleaning up our code and investigating some future changes to Avalon, including looking at alternative player options and other ways to handle group management. If you have any feedback about what functionality you want to see in future releases, please join us at next week's webinar!

 

Click here to watch the full recording of this week's demo. 

  • Player Investigation (VoV 1543) - Phuong (0:00:00)
  • Hydra Group Management Investigation (VoV 1577) - Chris (0:10:32)
  • Future Releases and Bug Fixes Path (VoV 1446) - Michael (0:19:23)
  • Rails Best Practices (VoV 1549) - Chris/Adam (0:32:07)
  • Review of Sprint Stories – Team led by Steve (0:35:26)

You can see the demos for past Sprints here or learn more about our development process here.

Blog Categories:

Upcoming Avalon Webinar - May 29, 2013

 

We're looking forward to talking with the Avalon community about our recent 1.0 release--and we hope you'll join us! This will be an ideal time to familiarize yourself with 1.0, ask questions, and provide feedback to the team. We will record the webinar for later viewing by those unable to join us.

 

To receive connection information for the webinar, please fill out our registration form: http://tinyurl.com/avalon1-0

 

Date: Wednesday, May 29

Time: 12:00-1:00 PM EDT

 

Agenda:

  • Overview of version 1.0 functionality and the download/tryout options
  • Demo of version 1.0
  • Roadmap and schedule for planned future releases
  • Questions and feedback from participants

Blog Categories:

Pages