Re: [Slim] Issue 43: How to know the modality of a language indication?

[Gunnar Hellström <[e-mail]>]

Den 2017-10-14 kl. 20:03, skrev Bernard Aboba:

> Gunnar said:
>
> "Applications not implementing such specific notations may use the 
> following simple deductions.
>
> - A language tag in audio media is supposed to indicate spoken modality.
<GH>This proposal was intended to express approximately the same as the 
current 5.4, but in a more strict way, being easy for applications to 
use and allowing for extensions.
We have now (in version -16 reduced the defined modalities to sign 
language in video, written in text and spoken in audio. That is 
simplification enough for the review comment to be satisfied.
It seems too complicated to get agreement about this rewording so we can 
drop the proposal. The already done rewording in 5.4 in version -16 to 
say that other use of language tags is not defined in this document 
opens well for other work to add new valid media/modality/language tag 
combinations.

I continue answering your questions anyway.
>
> [BA] Even a tag with "Sign Language" in the description??
<GH>Yes. The receiving application would trust the sending application 
and know that a language tag in audio is not a sign language tag. If it 
was anyway, a match would be very unlikely.

>
> - A language tag in text media is supposed to indicate  written modality.
>
> [BA] If the tag has "Sign Language" in the description, can this 
> document really say that?
<GH>The idea is to have a simple rule to meet the needs indicated by the 
review comment.
>
> - A language tag in video media is supposed to indicate visual sign 
> language modality except for the case when it is supposed to indicate 
> a view of a speaking person mentioned in section 5.2 characterized by 
> the exact same language tag also appearing in an audio media 
> specification.
>
> [BA] It seems like an over-reach to say that a spoken language tag in 
> video media should instead be interpreted as a request for Sign 
> Language.  If this were done, would it always be clear which Sign 
> Language was intended?  And could we really assume that both sides, if 
> negotiating a spoken language tag in video media, were really 
> indicating the desire to sign?  It seems like this could easily result 
> interoperability failure.
<GH>Yes it would result in interoperability failure. A match would be 
very unlikely. But the sentence means that  the sending application 
should only put sign language tags in the video description and the 
receiving application could trust that the tags in video descriptions 
are sign language tags. ( except for the exception that we are now 
prepared to drop if all agree. (already gone in version -16))
>
> - A language tag in media where the modality is obvious or specified 
> for the media subtype definition is supposed to indicate that modality.
> - A language tag in other media descriptions than above has undefined 
> modality."
<GH>these two were maybe the more important additions plus the 
mentioning in the beginning of a possibility to add indication of 
modality to a media specification or a language specification by further 
work.

/Gunnar



> On Sat, Oct 14, 2017 at 1:21 AM, Gunnar Hellström 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Den 2017-10-14 kl. 04:25, skrev Randall Gellens:
>
>         At 1:46 PM -0700 10/13/17, Bernard Aboba wrote:
>
>              Issue 43 ( <https://trac.ietf.org/trac/slim/ticket/43
>             <https://trac.ietf.org/trac/slim/ticket/43>>https://trac.ietf.org/trac/slim/ticket/43
>             <https://trac.ietf.org/trac/slim/ticket/43> ) results from
>             a review comment that said that a simple way is required
>             to decide if a language tag is a sign language or a
>             written or spoken language.
>
>              Some applications scan the IANA language registry at
>             startup for the word "Sign" in the tag description:
>
>             <https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
>             <https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry>>https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
>             <https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry>
>
>
>
>              Currently, there are 319 language subtags that include
>             "Sign Language" in their description.
>              Given the current layout of the language subtag registry,
>             it is not clear to me that there is an easier way to
>             determine which tags represent sign languages.  Nor is it
>             within the SLIM WG charter to develop a modification to
>             the language subtag registry to address this concern.
>              So I am wondering whether we might resolve this with a
>             Note outlining the problem but not offering a solution.
>
>
>         I think the wording in -14 addresses the comment by accepting
>         Dale's suggestion that, rather than know non-signed tags, it's
>         the use of the exact same tag in both an audio and a video
>         stream that is the indicator. That both tightens up the
>         technical issue and simplifies it greatly.
>
>         The only other instance where we might add such a note would
>         be in 5.4:
>
>         5.4.  Undefined Combinations
>
>            With the exception of the case mentioned in Section 5.2 (an
>         audio
>            stream in parallel with a video stream with the exact same
>         (spoken)
>            language tag), the behavior when specifying a non-signed
>         language tag
>            for a video media stream, or a signed language tag for an
>         audio or
>            text media stream, is not defined.
>
>         We could add your suggested note to 5.4.
>
>     <GH>We can replace 5.4 with a more explicit section guiding
>     applications to how to make the deduction simple. So, instead of a
>     note, I suggest that we replace 5.4 with:
>
>     5.4 Relations between media and modality
>     There is no easy way to deduct the intended modality from a
>     language tag. Other specifications may introduce specific
>     notations for modality used in a media or in relation to a
>     language tag. Applications not implementing such specific
>     notations may use the following simple deductions.
>     - A language tag in audio media is supposed to indicate spoken
>     modality.
>     - A language tag in text media is supposed to indicate written
>     modality.
>     - A language tag in video media is supposed to indicate visual
>     sign language modality except for the case when it is supposed to
>     indicate a view of a speaking person mentioned in section 5.2
>     characterized by the exact same language tag also appearing in an
>     audio media specification.
>     - A language tag in media where the modality is obvious or
>     specified for the media subtype definition is supposed to indicate
>     that modality.
>     - A language tag in other media descriptions than above has
>     undefined modality.
>     ---------------------------------------------------------------------------------------------------------------------
>
>     My note:  by this we currently consciously exclude the following
>     use and I am ok with that:
>     -text in mp4 video
>     -audio in mp4 video ( or is that only allowed in application/mp4 ??)
>     -any modality in message media
>     -most application media, however some may have explicit
>     descriptions in subtype specifications.
>
>     The exception with a view of a speaker stands out as very odd now,
>     requiring comparison of language tags used in different media
>     descriptions, and requiring simultaneous use of language in two
>     different media that is otherwise out of scope for this draft. It
>     was introduced while I still hoped that we could introduce other
>     dependencies between language use in different media.  It is not
>     the most urgent media/language combination to specify. It is also
>     handled in draft-hellstrom-slim-modality-grouping. So, assuming
>     that we can get progress on that draft, we could clean up the
>     current draft by deleting the exception. I suggest that we delete
>     the exception.
>
>     /Gunnar
>
>
>
>     -- 
>     -----------------------------------------
>     Gunnar Hellström
>     Omnitor
>     [e-mail] <mailto:[e-mail]>
>     [phone] <tel:%2B46%20708%20204%20288>
>
>
>     _______________________________________________
>     SLIM mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/slim
>     <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]