RFC: Editoria Data Model
Been working on this with @alexgeo over the last few days.
Uploading a diagram to get the point across clearer.
- Contributors and funders are essentially part of the book's metadata. But we keep them separate, in order to allow for them to exist across multiple books, and answer questions along the lines of "tell me which book X has contributed to".
- Translations are kept separate from the objects, so that they can swapped quite easily. Creating a new book will automatically create its english version, so the experience in the app will be seamless.
- Collections (not necessarily the collections that exist in pubsweet server) are groups of books.
- Anything can be locked without modifying the object's data.
- Files can be attached to a book component, a book or a division. This is tracked by a simple id, so moving them from one place to another should also be as simple as changing that id.
There is one limitation, quite possibly an edge-case, but it should be a consideration.
Bookbuilder divisions are configurable. This means that while data has already been produced by the system, someone can change the divisions of the bookbuilder by editing the configuration files. Any handling of existing data to accommodate that change would be doing some heavy assumptions.
To avoid all the above, we thought it would be sensible to say that divisions are read from the config only when the book is created. Any change in the config will only affect books that are created after the change.
Unbinding the divisions from the config after creation also opens up the road to possible features of changing the divisions only for one book, renaming them, reordering them etc without affecting the whole system.
This might seem like a configuration concern, but it has a real effect on how the data is stored.
If there is any objections to this, now would be a great time to discuss!