Following #191 make workflow type a registry, or remove it?

[nigelmegitt]

#191 introduces the idea of other workflows than dubbing and audio description that could be supported by DAPT, but the daptm:workflowType cannot be extended easily to accommodate them. Make it a registry instead.

[cconcolato]

How would this registry relate to the EBU ContentType classification https://www.ebu.ch/metadata/cs/EBU-TTContentTypeCS.xml which seems similar?

[nigelmegitt]

An alternative here is to remove Workflow Type altogether.

[nigelmegitt]

Thinking about how:

1. other uses might be unrelated to dubbing or audio description;
2. the same initial step might be used for both dubbing and subtitle production, as well as other uses;
3. considering if someone wants to use DAPT to author a pre-production script (a use case not captured so far), then they would begin without a transcription step.

I wonder if we should change approach, and instead of having a "workflow type", instead have metadata to describe what the document contents represent, e.g. the video image, the dialogue, the dialogue and the sound effects, maybe the dialogue that's not in some specified language.

contents represent	possible workflow deliverables
video image	(audio) descriptions
dialogue	dubbing scripts, translation subtitles, post production scripts
dialogue and sound effects	dubbing scripts, hard of hearing subtitles, translated hard of hearing subtitles, post production scripts (?)

In this scheme, we would not require metadata inside the document to indicate the intended workflow deliverables.

Does this sound like a plausible way forward, and an improvement? CC @andreastai @mattsimpson3 @cconcolato

[mattsimpson3]

@nigelmegitt that makes sense to me - there's nothing implied about future use, and I think it should be straighforward to articulate how the 'contents represents' metadata should be used...

[nigelmegitt]

ping @andreastai @cconcolato - before opening a pull request on this, I'd like to check if we have agreement on the direction.

[css-meeting-bot]

The Timed Text Working Group just discussed Following #191 make workflow type a registry, or remove it? w3c/dapt#194, and agreed to the following:

• SUMMARY: Prepare a Pull Request removing Workflow Type and adding "represents" or similar.

The full IRC log of that discussion

<nigel> Subtopic: Following #191 make workflow type a registry, or remove it? #194
<nigel> github: https://github.com//issues/194
<cpn> Matt: Want to avoid people down the process that the data was created for a single purpose
<cpn> Nigel: Could be used as a source of subtitles or dubbling, so forcing into a particular workflow not helpful
<cpn> Matt: Yes, what you do with it is your choice
<cpn> Nigel: I think we have consensus to remove workflow-type
<cpn> Cyril: Discussion about adding restrictions based on workflow-type. If you know it's a dubbing document you can validate there's no audio elements in it.
<cpn> ... Not saying I disagree with removing workflow types, but would still want an annotation that you can expect something specific from the document
<cpn> ... If we remove it, would we add another vocabulary, e.g., under 'represents'
<cpn> Nigel: Yes
<cpn> Cyril: So the proposal is to replace workflow type with something about what the content represents rather than what it was made for
<cpn> ... Early on, we discussed ttm:role for this
<cpn> Nigel: Could have multiple role values, and assign a mapping. If the role is description it's what's in the video image, if role is dialog, or music, or sound... Other things there that could be useful
<cpn> ... But ttm:role has both dialog and transcription. It's a flexible value set, but not clear which one should use
<cpn> Cyril: Still hesitant. Not sure if we should add a new attribute or use the existing one
<cpn> ... We discussed using EBU TT-D vocabulary
<cpn> Nigel: The content type is similar to what we have now
<cpn> ... So it would reproduce the existing issue we have with workflow type
<cpn> Cyril: Maybe we should work on a PR and iterate on that?
<cpn> Nigel: OK, yes
<cpn> ... Another option is to use ttm:item and a name, and a namespace for the values. But would take a lot of space in the document...
<cpn> Cyril: Could allow an empty value, or make workflow type optional. Or make it a registry, so anyone can register a new value
<cpn> Nigel: But that doesn't get rid of the problem with workflow type
<cpn> ... Let's make a PR, see how it looks
<cpn> ... Question about whether it should be a registry. Nothing depends on it right now
<cpn> ... Note about whether things are on screen or not, but no normative language
<cpn> Cyril: Let's work on the PR
<nigel> SUMMARY: Prepare a Pull Request removing Workflow Type and adding "represents" or similar.