Use Galleys in OMP and simplify SubmissionFiles

[NateWr]

Describe the problem you would like to solve
Publication Formats in OMP use SubmissionFiles as the unit of distribution, such as a PDF of a book chapter, an appendix, or supplementary data. Because of this, the SubmissionFile objects must support a lot of metadata that is not required during the editorial workflow, such as urlPaths, DOIs, licensing information, physical dimensions, credits and captions.

URLs for published submission files in OMP include the submission file id. This means that authorization policies must account for cases where the submission file is accessed during the workflow and cases where it is accessed from the published content. This makes the authorization logic for both cases more complicated than it needs to be.

For example, authorization logic based on the file stages works based on the stage assignments for most stages, but must work differently for files in the SUBMISSION_FILE_PROOF stage.

Describe the solution you'd like
OMP should use Galleys as the unit of distribution. Instead of assigning submission files to PublicationFormats, the user should create and assign Galleys to each PublicationFormat. This will allow us to migrate all of the publication-related metadata to Galley objects and share these objects across all applications.

The new object relations will look like this:

• OJS: Submission -> Publication -> Galley -> File
• OMP: Submission -> Publication -> Publication Format -> Galley -> File

All published metadata will be assigned to the Galley, including DOIs, urlPaths, licensing, etc. The fileId will reference a file in the files table, not in the submission_files table.

Pros

• Galleys become the unit of delivery for published files across all applications, so there is less difference in code between the applications.
• If and when we support remote submission files, we will have fewer features that need to be supported.
• The file stage authorization logic can be simplified. Because there is a one-to-one relationship between galleys and files, authorization logic for galleys does not need to concern itself with the file. Authorization can be provided to galleys based on existing policies determining stage access and published content.
• Remote galleys can have full metadata without any extra effort.
• Because galleys have a one-to-one relationship with files, URLs never use a file ID directly. This will make it easier to track usage data for remote galleys without making exceptions based on the file storage location. Usage data is only tracked by galley, not by file.
• It might be possible to off-load all dependent file handling to Galleys.

Cons

• This is a significant refactor with little benefit to the end-user.

Challenges

• Submission files still need to be be organised by chapter during the editorial workflow, to make it easier to find the appropriate file to be reviewed, copyedited or typeset.
• There is a lot of code around Representations which aligns Galleys and PublicationFormats. This would be tricky to pick apart.

Who is asking for this feature?
This should make it much easier to maintain existing code and develop future features, such as remote file support and OJS/OMP convergence.

[asmecher]

@NateWr, much of the weirdness in the relationships between submissions and publication formats stems from the ONIX standard, so we should definitely review this issue with reference to ONIX. In particular all the characteristics of the publication format (sales info, physical dimensions, etc) are ONIX beasts.

[NateWr]

@asmecher I think that this could be implemented without touching publication formats too much. Because the Galley in OMP would sit below Publication Formats, the only thing that would change is that instead of having submission files assigned to publication formats, galleys would be assigned to publication formats. All of the ONIX metadata would continue to live with Publlcation Formats.

[NateWr]

This feature request for remote chapter files is another example of how this would be useful in OMP. Because chapter files interact directly with the submission file, instead of publication formats or galleys, they do not support remote files. If galleys were introduced to OMP, they would support remote chapter files.

[NateWr]

Two more related requests: the ability to configure which file types support DOIs or remote URLs.

[nils-stefan-weiher]

Hi @NateWr ,

but then what is the difference between the publication format and the galley in OMP.

Wouldn't it be possible to extend the Galley metadata for OMP?

EDIT: I'm writing because, we will start a plugin for choosing a Galley Viewer from the publication format. And also because we need remote chapter files for this viewer basically.

[NateWr]

Hi @nils-stefan-weiher,

This would be the relationship between a publication format and a galley:

Submission -> Publication -> Publication Format -> Galley -> File

So one publication format may have many galleys. Just like right now one publication format may have many files.

[nils-stefan-weiher]

I'm slowly trying to grasp the concept, because in OMP we also have the association with chapters. Dont know how they fit in theire, because at the moment they are associated with a submission file directly (I suppose, not 100% sure)

[NateWr]

Galleys would be associated with chapters for the publication details. Depending on what workflow requirements existed, they may or may not be associated with submission files.

[nils-stefan-weiher]

Thanks @NateWr , so this makes sense to me. Also with the requirement for remote galleys for chapters.

On another note, please consider to move the association of chapters to galley to the main table of chapters and not the chapter settings. This would be simplify many queries.