Ontology Use Case: Evolution of Translation Project (text=>audio)

[jonathanrobie]

This is a use case to explore what Scripture Burritos would be created and how they relate to each other. The purpose is to explore how SBs are modeled, looking at ontologies and relationships.

1. A project is started as a text-based bog-standard Paratext translation. At this point, all files in the project are text.
2. One of the people who creates back translations prefers to do so orally. We want to include audio of the back translation as part of the project.
3. These back translations are transcribed in order to produce a text-based equivalent. They are also added as part of the project. Ideally, the SB should indicate that they are related.
4. The translation is finished. Now the texts are recorded and made available via Scripture App Builder. Consider two cases: 4.a. The administrators see these recordings as part of the same project. 4.b. The administrators see these recordings as a separate project

[mvahowe]

The first thing I see here is that we need a way to represent back translations.

One option is to make a flavor for an audio backtranslation, and for a text backtranslation. I think this would be within the "gloss" flavorType, since no-one is going to treat the back translation as "Scripture" for external consumption, but a gloss follows BCV closely.

Another option would be to augment the scriptureText flavor to support optional backtranslation resources in text and/or audio format.

Both of these options are easily doable within SB. Both these options would "work". Choosing between these options would depend on questions like

• do backtranslation texts or audio ever follow a workflow separate to the translation text?
• to what extent are backtranslations in text or audio reusable?
• does it make sense to publish a new revision of a SB for all users whenever either the translation or the backtranslation changes?
• how much pain would be caused by increasing the size of a text project from 5Mb to 500Mb, by adding audio, for situations where the audio does not need to be processed?

Due dilligence on those questions surely requires us to look at more than one organization's workflow for backtranslation, and at the tools that currently or potentially enable that workflow. The last question might require us to consider current and future Internet bandwidth in various parts of the world. But, in the absolute case, either option above (and, no doubt, many other variants) would "do the job".

Mapping between translation and backtranslation assumes BCV markers at least on both sides. Maybe we don't need versification, if the backtranslation follows the translation's versification. Even then, there's potentially a maintenance challenge as the translation and backtranslation evolve, out of sync. If we do need versification, we'd need it in two places. In that case the versification could be a resource in two SBs, or 2 separate versification SBs, or one of each. All of these options (and more) could "work".

I'd go for separate flavors for backtranslations because modularity is currently trendy and often beneficial. In other words, I don't think SB should assume single, do-it-all tools over a collection of one-purpose tools. But that's an argument from personal dogma that is not constrained by the use case, AFAICS.

[mvahowe]

@jonathanrobie You opened this issue four months ago, after one of the many meetings that we've wasted talking about the importance of use cases. I responded with specific details, the same day. You've never responded to those specific details. Why?

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?