November 20, 2019

Time/Place

Anyone is welcome to join this meeting. Here is the info:

• Time: 1:00pm Eastern Daylight Time US (UTC-4)
• Zoom link: https://zoom.us/j/203396828

Attendees

• Danny Lamb
• Melissa Anez
• Aaron Birkland
• Alan Stanley
• Alexander O'Neill
• Carey Gordon
• Chris Kellen
• Debbie Flitner
• Don Richards UTK
• Eli Zoller
• Jared Whiklo 🌠
• Noella MacIntyre
• Seth Shaw
• Willow Gillingham
• Yamil Suarez

Agenda

1. Islandora/Fedora Camp - who is planning to go?
2. Islandora 8 Special Topics Call: Core Islandora 8 Concept of an Object. Questions to pose? 1. From last week's call: "come with topics we want to discuss in a larger community meeting about what to expect from Islandora." The group agreed that we need to put some thoughts together on data modelling, so we can then get feedback from the wider Islandora community.
   1. One big question is what is the relationship between a resource node (which describes the work or thing) and the files that contain the content of the work or thing.
      • Currently, one resource node is associated with zero or more media. In Drupal terms, a media (or to follow the Latin, a medium 😸) encapsulates metadata about a single file. An important piece of metadata for each file is how the file is intended to be used, which is expressed using the "Media Use" vocabulary. Terms from this vocabulary include "Original file", "Thumbnail", and "Extracted text". So the model so far is: a resource node may have multiple media, but each media describes a single file, e.g. a single Original file.
      • This model poses a head scratcher: what if the content the resource node describes is not a single file, but is multiple files? For example, a video that is actually 3 separate .mp4 files. In the current Islandora data model, we can upload all three .mp4 files and tag them as "Original file", but Islandora assumes that there is only one original file media per resource node.
      • Another assumption Islandora currently makes is that if we want to associate all three .mp4 files with the resource node that describes them, we create a resource node for each file (along with the corresponding media and file entities) and then associate each of those resource nodes with the first one as children. So now we have 4 resource nodes (the first one plus one for each part of the video it describes) plus one media for each of the parts.
      • Some issues we need to discuss coming out of these assumptions include what is the UX for creating (and viewing) objects that have multiple files; how do we manage technical metadata (e.g. FITS) for each file; how does searching/browsing work for objects that have multiple files.
3. ... (feel free to add agenda items)

Minutes

1. Anyone planning to go?

   • No takers....yet?!

2. Big assumption being challenged (since Islandora 5) that we are preserving "objects" and each "object" has a single data file. The new use case is to have a single archival description for multiple data files. (Example is multiple files but a single "dataset"). Change is to have a single description (ie. media) and multiple "Original" files linked. Then we need to line up the various derivatives.

   So could we have multiple file references on a media, like an audio of an interview and the transcript of the interview but avoiding multiple middle entities.

   Problem is linking the various files to their derivatives so we can keep them...in order. Possibly using weights, so weight: 0 WAV audio file (Original File) matches to weight: 0 MP3 audio file (Service File).

   Alan has a module in the works that matches media based on the file names to link them together. (I think that's what it does)

   Major limitation is that the context is keyed off of fields that are on the media (to do derivatives, etc).

   What about a media referencing another media, so your main file would be the "Original File" media but you could also have a "Thumbnail" media and all of those map to an "aggregation" media that might have common metadata and that links to the node.

   Have a node that is an interview which has two media, one is audio and the other is a transcript. Most share all the same fields, but still have some differences.

   Perhaps have links between files so in Fedora the primary file (like weight == 0) would have all the media metadata flushed to its binary description in Fedora and the alternates would end up with a skeleton technical description. Possibly referencing the original files description.

   FITS could be a concern and would have to be aware of file naming conventions (ie. image-1,jpg -> image-1.xml and image-2.jpg -> image-2.xml)

   Extracted text is being persisted as a separate file, but if we are going to have more than one file then we might want that information stored as a field in the media.

   Being able to push the generated (derivative for example) content into a specific field on the media. Instead of as a file, tied to a media, tied to the node.

   One node -> 5 original files, each contains an audio and transcript or one node, with a media with 5 files.

   In the end we are looking at storing multiple files on a single media.

   
   

   maybe