search

sul-dlss / happy-heron

Self-Deposit for the Stanford Digital Repository (SDR): H2 is a Rails web application enabling users to deposit scholarly content into SDR
Apache License 2.0
10 stars 2 forks source link

Image, audio, and video content types should not be treated as "file" #608

Open amyehodge opened 3 years ago

amyehodge commented 3 years ago

kj651xq2913 (https://sul-h2-qa.stanford.edu/works/42) was deposited with an image file, but it displays as a normal file on the purl, not as an image. See https://sul-purl-stage.stanford.edu/kj651xq2913. Metadata matches with this behavior. See https://argo-qa.stanford.edu/view/druid:kj651xq2913

`

`

I also tested one with video: nf978bf5719 (https://sul-h2-qa.stanford.edu/works/43). Displays as file on PURL: https://sul-purl-stage.stanford.edu/nf978bf5719 Similar to metadata as the one above: https://argo-qa.stanford.edu/view/druid:nf978bf5719

`

63b8812b0c05722a9d6c51cbd2bfb54b 5d39343e4bb48abd97f759828282f5ebbac56c5e

`

Background: I have a note that Justin indicated at our meeting on the 24th when we were reviewing the Hydrus feature list that I should test to see if image/video/audio files are being treated like they are in other workflows — in other words, not just as files.

andrewjbtw commented 3 years ago

A few notes on this issue:

The content type determines the type of viewer that gets displayed on the purl, and that instruction (to display the viewer) is followed even if the chosen viewer doesn't support the file formats contained in the object. For example, the image viewer will display for content type image regardless of whether an object has any image files that the viewer supports. If the format isn't supported, the user will see an error in the viewer.[1]

Even with supported file formats, there are complications around mixed media content: text and images, text and video, etc. In some cases, one file format will display in the viewer and the others will be available using the download button. There may not be an indication that the download-only files exist outside of the display that you see when clicking on the download button.

Ideally, to make content type support work for self-deposit we need:

  1. A set of validation rules that can determine whether the deposit's files are supported in that content type's viewer
  2. A fall back to show the file viewer if the other viewers can't display the deposit
  3. Some guidelines on how to handle mixed media content

[1] Note that SDR does support creating derivative JP2 image files that will work in the viewer. This takes place in the assemblyWF, which the SDR API currently skips. Derivative creation can run into errors, especially with files that weren't created to the specs used in the imaging lab, so there's a risk that sending self-deposit files through jp2-create will delay deposits while someone tries to work out the errors.

amyehodge commented 3 years ago

@hannahfrost I wanted to be sure you saw @andrewjbtw 's comments above.

jcoyne commented 3 years ago

@amyehodge the item https://sul-h2-qa.stanford.edu/works/42 (as well as https://sul-h2-qa.stanford.edu/works/43) was given the type "data", so it gets a file type for display purposes.

ww = Work.find(42)
ww.work_type
# => "data"

I suspect if you set the type to "Media" you'll get the display you're looking for.

hannahfrost commented 3 years ago

Thanks, @amyehodge and @andrewjbtw. As I suggested in the H2 planning meeting today, let's plan to revisit this requirement down the road a piece, after Hydrus migration to H2.