Enhancement: Constrain available Media Use terms to relevant addable media types

[kspurgin]

Currently, if I go to Content > Media and click the Add Media button, I first have to choose a media type (Audio, Document, Extracted Text, File, FITS Technical metadata, Image, Remote video, or Video).

If I select Audio, I am taken to an "Add Audio" form.

The list of check-able Media Use terms for my audio file include all the Islandora Media Use taxonomy terms, even though most of them are relatively nonsensical for an audio file.

What even happens if I indicate that my Audio file is Media Use: FITS File? Why can I say an audio file should be used as a Thumbnail Image? Presumably there's a reason for making Media Use value selections, and being able to set them so wrong is concerning.

Having to choose from the entire list increases cognitive load and opportunity for user error.

A possible solution?

• Add an "Applies to Media Type" (or some other name) field in the Islandora Media Use taxonomy. This should be a multi-valued field. Its allowable terms are the "Add Media" types.
• The form at media/add/* pages use a view of the Islandora Media Use taxonomy limited to "Applies to Media Type" = * to generate the list of Media Use terms in the form

Appropriate mappings (initial/tentative)

Top level: Islandora Media Use terms

Indented level: Addable media types

Note: On the media/add page, some clarification of the difference between Document and File would be useful. I am proceeding assuming that Document expresses something about being a human readable formatted document (which would include .pdf and .docx and .odf formats among others), while File is more about plain-text files primarily for system use.

• Audit Trail
  • file
  • not defined in https://pcdm.org/2015/05/12/use but described in taxonomy term as "Audit trail generated by Fedora 3"
• Collection Policy
  • file
  • not defined in https://pcdm.org/2015/05/12/use but described in taxonomy term as "Islandora 7.x Collection Policy File"
• Dublin Core File
  • file
• Extracted Text
  • extracted_text
• FITS File
  • fits_technical_metadata
• Intermediate File
  • audio, document (?), image, video
• MODS File
  • file
• Original File
  • audio, document, file (?), image, video
• Preservation Master File
  • audio, document, file (?), image, video
• RELS-EXT File
  • file
  • not defined in https://pcdm.org/2015/05/12/use but described in taxonomy term as "A RELS-EXT file from an Islandora 7.x instance"
• Service File
  • audio, document (?), file (?), image, video
• Thumbnail Image
  • image
• Transcript
  • document, file
  • Unclear what the function of this is, from the taxonomy description: "A textual representation of the Object appropriate for presenting to users, such as subtitles or transcript of a video. Can be used as a substitute or complement to other files for accessibility purposes" -- if this should be usable by system for subtitles or video/audio-to-transcript text sync, probably only file is appropriate. If this should be a transcript that itself (on its own) is appropriate for presenting to users, then both document and file seem appropriate

[seth-shaw-unlv]

I suppose we could add a form alter hook that filters the available options based on a Type→term mapping (the inverse of the one in the OP for efficiency's sake) stored in config. The hook would be relatively simple, the config form would be a bit more difficult but still do-able.

OR we can add a field to the taxonomy allowing you to select which types it applies to and ~use a view filter on the form~, that may be simpler (and purely config!)... Edit: I thought you could add a filter on an entity reference form field, but I'm not finding wrong and must have been thinking of something else... ☹️

As for the types in question marks, I would say yes to each of them, but also add 'file' to Intermediate File. We have edited Tiffs that are Intermediate Files which Drupal consider to be the File type.

[kspurgin]

I may not have the terminology right, but I'm pretty sure you can add a filter to an entity reference form field (i.e. one populated with a taxonomy term).

In poking at another problem, I'd created a Role Type taxonomy with a Role Category field (creator, contributor, publisher, etc) for each term.

I was able to create a Creator field on my content nodes and a Creator form field populated from the Role Type taxonomy, but limited only to terms with Role Category = creator.

Since I actually made that work elsewhere, that's why it popped to my mind as a solution here.

I have no clue whether it's the BEST solution, and I also wondered if the "show the term options as checkboxes in the form" instead of "populate a dropdown in the form" might not work, but that seemed like it would be weirdly inconsistent behavior and I hoped it wouldn't be a problem.

[dannylamb]

I think multi-file media may alleviate this. It doesn't use Media Use terms, and instead you would use analagous field names. E.g. an Original File is not tagged as such, instead it lives on the media as field_original_file.

Right now it's totally do-able, but we have zero documentation on it. It's still new.

[kspurgin]

@dannylamb Is that the same "multi-file media" referenced here: "Multi-file Media configurations also attach Media to a parent node, but allow for that node to be represened by multiple "Original File"s. In this model, a Media contains the original file as well as any derivative files created from it (thumbnail, service file, etc.)."

If so, do you think that alleviates this because (guessing) whatever files are added to a resource node as Media using that model are assumed to be original files, and then the system tracks the use/types of derivative files created?

Though it sounds like using multi-file media would be an option and this issue would still remain when uploading Media to content nodes not using multi-file media model. (?)

[dannylamb]

Yes it is the same. And yes, it "solves" the problem by entirely sidestepping it, which doesn't help folks who aren't using the multi-file media approach. So maybe it wasn't that helpful of a suggestion. We'll still need to find a way to lock things down how they work right now.

[kspurgin]

Here I have added a File media type (.txt file) with Media Use value = Thumbnail Image. No warnings or complaints!

Of course I get no thumbnail:

I try again and actually do it right. It totally lets me attach two media with Media Use value = Thumbnail Image to the same node. No warnings or complaints!

Doesn't fix the actual display as long as the bad media file is there:

Deleting the media/file of the File media type makes my fixed thumbnail show up.

[kspurgin]

But why would you DO THAT?

Because you can. So someone will. On accident or out of sheer confusion. And they shouldn't be able to, because a system should be smart enough to know it can't use a .txt file as a thumbnail or a .mp4 as a FITS File or whatever other weird quietly not-working possibilities are currently available.