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

[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 an audio-based oral translation. At this point, all files in the project are audio.
2. Consultants decide they need to be able to check for consistency with biblical terms and perform other checks that require text, so Transcriber is used to create equivalent text. These are added to the project.
3. The translation is finished. Now the texts are recorded and made available via Scripture App Builder. Consider two cases: 3.a. The administrators see these recordings as part of the same project. 3.b. The administrators see these recordings as a separate project

[mvahowe]

I think the translation would be scriptureAudio. Maybe, for translation as opposed to publication, we need additional resources. I have no idea what resources we might need.

A text translation could be extra resources for scriptureAudio or a related scriptureText or backtranslation burrito, or probably something else.

Recordings for distribution would be separate scriptureAudio projects, as at present in DBL.

[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?

[jonathanrobie]

Mark, I really do need to know how Scripture Burrito would solve specific kinds of problems in order to know whether it meets basic requirements. And sometimes it takes time thinking through use cases together to understand other possible requirements.

Currently, Scripture Burrito is still heading toward 0.2, which is essentially trying to do things that Paratext and DBL already do now, use cases are less important for that. As we move beyond that, I think we will need to be able to think about other things we need to be able to do or represent.

I get the impression use cases are not the way you generally think. We are different people, we think differently, but I do need to be able to do things like analyze use cases and ask questions about how scenarios can be handled to know what this is for and whether it meets the requirements of my systems.

[mvahowe]

I'm just not seeing how spending time creating use case issues last November served any purpose whatsoever. What am I missing?

[jonathanrobie]

Before I started asking about use cases, there were huge gaps in my understanding of Scripture Burrito that I was unable to infer from the specification, which does not yet always explain why each bit is there or the relationships among the various bits. That led, for instance, to our discussion of recipes and recipeSpecs and variants.

The meaning of these things is also in flux, which makes it harder to follow sometimes. I use use cases as a lens to see how things work, understanding the individual pieces in that context.

Another possible difference: sometimes I get the impression you have more of a static view of systems, where I tend to have more of a dynamic view.

When I don't understand you, use cases really help me. When I am not sure if we have a shared direction or whether my requirements can be met, use cases really help me. They don't seem to be a big part of the way you work, so they may be more for me than for you.

[jonathanrobie]

A little background: when we designed XQuery, we started out with 5 candidate query languages as the basis, and in order to evaluate them, we came up with a set of use cases that gave an idea of what we wanted a query language to do.

XQuery 1.0 Use Cases

Working through them took time, but they helped us think more concretely together. I think that will be particularly valuable when (1) we need to be able to better say what the individual features are for in our specification or (2) we are designing new functionality and want to envision how features will work together to solve concrete problems.

I can show you how we did this with the Assignments and Progress feature we are working on in Paratext. I think the general consensus is that it was very helpful.

[mvahowe]

I'm still not seeing where any of these specific use cases helped anyone. They were created and they have sat here, untouched, for 4 months, and now you want to make some more of them.

[jonathanrobie]

At this point, I think most of us would put the oral source, the text transcription, and the audio Bible produced from the text into separate burritos. It would be useful to have a way to describe the relationships among these burritos using identifiers. We are unlikely to ever be able to enumerate all possible relationships, but we might or might not want to specify some.

In this case, the oral source might be seen as transitory, used for reference to create the text transcription, and the audio Bible would be considered the actual audio product. The text translation might be seen as equally authoritative, and they might be defined as equivalent. Is that another relationship that needs to be expressible?

Maybe the right starting point is to allow a relationship to be specified, make it at least extensible, and get a feeling for how important it is to be precise and what relationships are important to express.