Page tree
Skip to end of metadata
Go to start of metadata

R1 Functionality (Notes from 9/20 F2F discussion)

  • Mobile device support
    • Playback only (functions include native playback on iOS and Android)
    • No ingest function
    • Scale back options:  
      • Mobile function does not include support for a mobile site, meaning end-user playback is the main goal for mobile support.  
      • Search, browse, via mobile is not important for R1.
  • Scalability
    • Large file ingest (150 GB?)
    • Paging of results 
    • Scale back options:  
      • Keep to single items uploaded via web browser
      • Use Matterhorn dropbox? We need some kind of non-browser-based upload option.

  • Works with Red5 and Flash streaming servers
    • Could drop for pilot, but we'd need it soon. We don't know what limitations Red5 has
  • Authentication and group-based authorization for access control 
    • Integrates with LDAP and Kerberos CAS (connect, log in to system) (OmniAuth); there is also local database; for pilots, partners implement their own OmniAuth modules
    • Authorization means manually assigned group-based permissions for access to objects and system functionality
    • No connection to student info system
    • Collections can have a default set of permissions (good for NU pilots)? This sounds larger, as we have no collections yet. We will discuss later.
  • Support for more comprehensive descriptive and structural metadata
    • Descriptive metadata decision made and support for it in the system (for batch upload, editing, creation of new records (cataloguing) ) to support search/browse
    • Enough structural metadata exists to allow user navigation of chapters, tracks, scenes (RELS and another schema for add'tl structural?) and for indexing to support better search. Metadata points to timecode, so users can jump to media section. (this is distinct from clip making)
    • Scale back options: 
      • take out technical metadata
      • take out structural metadata - (Very important for IU Music pilot, not important for NU pilots) ; one of the biggest hurdles is the interface for building this; one simplifying option is to not do hierarchy initially, just supporting a flat list of labels/timepoints; another option could be batch upload rather than supporting it in the UI; if there's one player for files, need to have a way to navigate between them
  • Batch import of media and metadata
    • Should support small batches (TBD number or size of media) because we don't expect pilots to require large amounts of media.
    • Define a means by which content can be batch-ingested (includes structural metadata, descriptive metadata and files)
    • Scale back options:
      • Do not offer batch import of files or metadata but try to add that for R2 - 2-3 months after R1. Batch import from a CSV file would be relatively easy; What about MARC import? 
      • Questions: 

        1. does this affect large file upload, will we still need to deal with large file ingest not via web browser
        2. can we just batch files and catalog via the web since automating structural metadata is an unknown. 

  • Administrators will be able to monitor their installation of Avalon to quickly detect and troubleshoot problems 
    • we should define a hierarchy of monitoring/troubleshooting and then just do the most essential. There's a Hydra plugin that can help define server status & some other stuff. Not so scary.

Take out clipmaking and playlists We made this decision earlier in the year–yes, take it out.

Other questions: UI logging? Probably not needed for R1

  • No labels