2016-11-21 Radio Haiti "Item-ness" and A/V

Date

21 Nov 2016

Attendees

• Molly Bragg

• Sean Aery (Old Account) (Unlicensed)

• Cory Lown (Deactivated)
• Jim Coble (Unlicensed)
• Ayse Durmaz
• Maggie Dickson (old account) (Unlicensed)
• Jack Hill
• David Chandek-Stark

Goals

• Review / set data model for Radio Haiti
• Discuss A/V for Radio Haiti as time allows

Discussion items

Itemness:

→ what about metadata on the "tapes" tab?  do we need to preserve this information in anyway. 

files are items

items have one component that have 1 audio item.  

Differnt types of items - are listed on the project info. 

Structural metadata could help solve some of these issues – but a descriptive metadata approach may be better for RH. 

Questions:

• Are there overlap between the types of items? 
• Are things that are sequential also copies of something else.  

Suggested approach:

• Use the same solution we used for Duke Chapel recordings.  
  
  • Instead of using the "series" field, use "category" to note relationships between items.  This is an unordered relationships. 
    • We can potentially force the items to sort in order based on file ID. 
    • This is the simplest approach. 
  • Using "relation" on the collection level to handle the lib guide links. 
• We can have different kinds of related items, but not in a sequence. 
• They way we have created sequence order has been w/ METS in Tripod2. 

alternate approach:

• Single item w/ multiple components and structured metadata
• DDR does support structured metadata but only w/in an item.  Changing this to support multiple items could be overly complicated.

Mock ups:

• ask Craig and Laura to point us to at least one example of each type of relationship. 
• We will create some mock ups from there. 

A/V in General

• We can fall back on the Chapel Recordings solution for this collection if need be. 

Plan is going to use RH as the driving force to getting a solution together.  

Avalon is out. 

Warpwire is the current exploration focus. 

• Warpwire would accommodate the high and low resolution copies elegantly. 

Time synced metadata

• We could possibly do something where the time codes display as links and could use those to click to that time of the file. 
• Sub-description would be indexed for discovery. 
• Could bookmark a timecode and use that as a link. 
• Also a possibility to use chapter information.  

General plan:

• find the long term A/V solution first
• Captions / time-coded metadata features are part of our requirements for the tool. 

Access from Haiti:

• Back up:  dump a copy of all the A/V on YouTube w/ Haitian metadata
• How light-weight is DDR?
  • Its the actual media that slows everything down?
  • If we are delivering low-fi files, will that be sufficient?
  • Warp-wire checks bandwidth of the end users and delivers file appropriately. 
• YouTube:  advantage is the content delivery network. 
• Questions:  how heavy is the DDR-Public now?
  • Can we use this project as a way do some testing on DDR-Public?
• Maggie:  panel at DLF on distributing content to low-bandwidth locations.  

Launching in general:

• If the files are not all ready, how should we handle the launch?
  
  • Metadata:  if all the metadata isn't standard then there could be issues w/ later batches that we don't find at the beginning.  
  • ingest/launch:  we would like fewer big chunks of material than infinite small chunks.  
  • Lets try and just ingest what we can launch at the time so we do not have to separate things that will be launched and not launched. 

Next Steps:

Molly to ask Craig / Laura questions

Cory to spearhead more mock ups

Action items