Open mvahowe opened 5 years ago
I think this use case demonstrates why do-it-all storage formats are a bad plan, since they limit reusability. If, eg, text and audio live in the same burrito, it becomes impossible to update either the text or the audio independently of each other, which places a heavier burden on the revision team.
Also, the more content in a burrito, the more potential VC issues arise. Resolving text-based VC conflicts can be hard. Resolving audio or video conflicts, or even detecting them, is pretty much impossible. Audio revisions might reflect changes in the text, or simply better recording, or a different style of recording. Separate burritos with relationships and other information in the metadata handle this better than mega-burritos.
@jonathanrobie I opened this issue four months ago, after one of the many meetings that we've wasted talking about the importance of use cases. Why haven't you engaged with it in any way?
Everyone else, how has the existence of this use case contributed anything useful to any aspect of Scripture Burrito? Depending on the answer, why would we want to waste any more time making up use cases?
I think we need to distinguish two kinds of source:
I think we also need to think about what happens if we say "update all of this for the latest text". With some of the humanly produced stuff, that won't be possible in some cases and they will continue to use a version, so knowing what version it was produced from is particularly important ...
@jonathanrobie Looking at the docs in the relationship section, the relationType
property does mostly cover what you've talked about.
A team prepares a text translation.
Someone records this as audio.
Someone else makes a video of the audio with text subtitles and clipart images
Someone else generates braille
Someone else uses the translation as a Paratext resource
Meanwhile, the team is working on the next revision of the project