-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support within workflowType for generic script origination #169
Comments
The Timed Text Working Group just discussed
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. |
I've been giving this some more thought, and am beginning to think that
We could also add a |
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'. |
I still think the Although the |
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 Thinking from an accessibility perspective, another option would be |
I agree that if you use DAPT to represent a transcription of the audio for the purpose of subtitling and captioning, using I thought of the following alternatives:
|
Trying to understand this use case. Is it to provide a translated alternative to in-image text? |
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):
|
As discussed during today's TTWG call, decided to make the list into a Registry Table for ease of adding future values. |
The above change now done in #217. |
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.
The text was updated successfully, but these errors were encountered: