Support within workflowType for generic script origination

[mattsimpson3]

Our (ITV) usecase for DAPT centres on using DAPT as a generic script exchange format, that may flow into either a SDH caption or dubbing workflow.

On reviewing the details of the profile, it's clear that workflowType supports either 'dubbing' or 'audioDescription'. Neither of these captures a script creation workflow that could be either SDH captions or dubbing.

The property is mandatory, and as it stands we would need to populate it with 'dubbing'. That's the closest to our use-case - but it feels less than desirable as it doesn't capture the full scope of our intentions with the file.

[css-meeting-bot]

The Timed Text Working Group just discussed Support within workflowType for generic script origination w3c/dapt#169, and agreed to the following:

• SUMMARY: Helpful to clarify if worfklowType is intended to capture current state or end outcome; adding a transcription value could be commercially useful for some user groups.

The full IRC log of that discussion

<nigel> Subtopic: Support within workflowType for generic script origination #169
<nigel> github: https://github.com//issues/169
<nigel> Matt: Looking at the detail for this, we've been thinking that this would be a useful starting
<cpn> Matt: I looked at some of the detail in the spec. We have been thinking that a structured script file we can commission people to produce, e.g., third party, would be a useful starting point for subtitles for deaf and hard of hearing, and dubbing and translation workflows
<nigel> s/Matt: Looking at the detail for this, we've been thinking that this would be a useful starting//
<nigel> Nigel: yes, daptm:workflowType
<cpn> ... There's a workflow type property. It's mandatory, either dubbing or AD. When we commission one of these, it could also be used for subtitles for deaf and hard of hearing and for translation subtitles as well as dubbing
<nigel> s/.../Matt:
<cpn> ... At the moment, we'd mark it up as dubbing, but that would be erroneous
<cpn> ... We don't necessarily know which of the subtitling, dubbing, or translation subtitling it might need to flow through. It could be one or all three
<cpn> Nigel: Are you proposing a new type?
<cpn> Matt: I think so, but don't know what I'd call it
<cpn> Nigel: Would transcription work?
<nigel> s/new type/new value for workflowType
<cpn> Matt: It needs to be something generic like that. Depends whether you see it as describing the workflow or describing what's in the document
<cpn> ... For commercial reasons, we might not want the third party to know it's being used for dubbing if they're not been commissioned to do that work
<cpn> Nigel: That's interesting
<cpn> Matt: Was there a view on whether the workflow is describing what it contributes towards?
<cpn> ... That was my reading of it
<cpn> Nigel: Yes. I can see that being helpful
<cpn> ... Any other thoughts on this?
<nigel> SUMMARY: Helpful to clarify if worfklowType is intended to capture current state or end outcome; adding a transcription value could be commercially useful for some user groups.

[nigelmegitt]

I've been giving this some more thought, and am beginning to think that workflowType is not a helpful thing to capture, in general: it is, as described in this issue, rather a "loaded" term. Rather, we should capture the source of the transcript or what the script is an alternative for, which should be the same thing. For example:

Current	Proposed
daptm:workflowType="dubbing"	daptm:represents="dialog"
daptm:workflowType="audioDescription"	daptm:represents="image"

We could also add a daptm:represents="dialogAndSounds" as the basis for hard of hearing subtitles.

[mattsimpson3]

Agree re the above point - but not sure if 'image' is entirely the equivalent of 'dialog'. It may need to be something more cumbersome - i.e. 'visualContent'.

[andreastai]

I still think the daptm:workflowType is useful and should be kept. Most users would understand the meaning of it and would use it accordingly. But the attribute could be optional or the value could be the empty string (like in xml:lang). It would mean "not specified". Furthermore, it could be made extensible with "private values" in the form x-[private-value] (e.g. x-sdh).

Although the daptm:represents would overlap with daptm:workflowType it could also be added and made optional.

[nigelmegitt]

I would generally prefer to settle on one way to describe the intent of the document and require it, than have two optional and overlapping ways.

I agree with the original point that since the initial part of the workflow may be common to both subtitles and dubbing, and that the supplier might not know or be told what the client's intent for the document is, it may be more confusing than helpful to keep daptm:workflowType as it is now.

Thinking from an accessibility perspective, another option would be daptm:alternativeFor.

[cconcolato]

I agree that if you use DAPT to represent a transcription of the audio for the purpose of subtitling and captioning, using dubbing is not adequate.
I don't think the represents proposal works as is. In dubbing (and subtitling) workflows you may want to transcribe also the image, to produce Forced Narratives. I also find the term daptm:represents="image" less clear than audioDescription.

I thought of the following alternatives:

1. adding a value subtitling, but in fact in many cases the initial transcription for subtitling and/or dubbing is the same. Maybe it should be called subtitlingAndOrDubbing but this would not be applicable for preRecording or asRecorded, so we would have:

workflowType	applicable with the following scriptType values
subtitlingAndOrDubbing	originalTranscript and translatedTranscript
audioDescription	all values
dubbingOnly	all values

2. another option is simply to remove the workflowType and mandate some signaling (e.g. isAudioDescription) when the document is about audio descriptions, and assuming that when not specified it's applicable to subtitling and dubbing workflows (for the original and translated stages) and only to dubbing for the other stages (preRecording and asRecorded).

[nigelmegitt]

In dubbing (and subtitling) workflows you may want to transcribe also the image, to produce Forced Narratives

Trying to understand this use case. Is it to provide a translated alternative to in-image text?

[nigelmegitt]

Ok, in that case I'm now tempted to suggest we define a structure that allows a list of the types of in-media content for which the document provides some alternative. Current known types are (please add to this list):

• dialog
• nonDialogSounds
• visualNonText
• visualText

[nigelmegitt]

As discussed during today's TTWG call, decided to make the list into a Registry Table for ease of adding future values.

[nigelmegitt]

The above change now done in #217.