-
Notifications
You must be signed in to change notification settings - Fork 2
Description
It's not always a submission of one work at a time. For example, poets send submissions that can include 5-10 works as part of a single submission. Visual artists submit multiple works at a time, very often. This does not count as the supposedly-dreadful "simultaneous submission" when, as with poets, the one submission is supposed to contain multiple works.
I can think of two ways to address this issue
1. Multiple Submission Records
create multiple submission records, one for each work submitted to the venue, even though technically it was just one submission. Pro: you can mark the status of each, in case some of the works were accepted but others were not. Con: you end up with multiple rows to represent what was really one submission.
2. A New Table
Create a new table, to allow for a one-to-many relationship among submissions and works. pro: one submission can include multiple works. con: it remains difficult to indicate what happened if only some of the works are accepted. for example, the table could look like:
TABLE: works_SUBS
DESCRIPTION: **This is not currently implemented** but there could be a one-to-many relationship from Submissions to Manuscripts
NOTE: If you submit multiple files, .zip or merge them first?
Manuscrpts can undergo revisions from one submission to the next
It is useful to store a reference (git?) to which version was sent
| FIELD NAME | DATA TYPE | DESCRIPTION |
|---|---|---|
| sub_nbr | integer | Foreign Key to indicate a Submission |
| venue_nbr | integer | Foreign Key to indicate a Venue |
| works_nbr | integer | Foreign Key to indicate a Work |
| sub_file | BLOB | Store a copy of the file that was submitted |
| sub_filename | TEXT | indicates what filename to use for sub_file |