Subject: RE: [Speechsc] Consolidated comments on NLSML

From: "Dan Burnett" <[email-masked]>
Date: Fri, 24 Mar 2006 11:38:36 -0500

Replying to verification comments first (since I'm working on that
section now).  See below.

-----Original Message-----
Speaker Verification Related:
-------------------------------------

o Clarify that grammar attribute on <result> is not present for
verification
results.

<DanB> Actually, it could be.  The original intent was to permit
recognition, verification, and enrollment results within the same
structure.  Because originally we were referring to NLSML externally, we
created the <extensions> and <result-type> elements (which are
incorrectly left over in some of the examples) as a way to extend that
external spec.  However, those aren't actually defined anywhere and are
redundant in the current spec where the contents of the enrollment and
verification schemas are to be understood as going directly into the
NLSML structure under the <result> element.
I'll remove the <extensions> and <result-type> elements from the
examples, which may help.  The MRCPv2 namespace declarations shown in
the verification result section are unnecessary now as well.
Technically we should now create just one XML schema showing a <result>
element containing all of the possible result pieces, but I believe the
chances of making a mistake at this point are greater than the value of
creating the combined schema.
</DanB>

o Element <needmoredata> not specified in the text but is specified in
schema. Obviously needed for training voiceprints. Note it should be
called
<need-more-data> for consistency. Why not have it as a childless element
instead of containing a boolean - its presence implies more data needed?
Shouldn't <need-more-data> be at the same level as <cumulative> and
<incremental> as opposed to being duplicated in both? Or at least
just be contained in <cumulative>?

<DanB> I believe this was removed from the text at some point, but I'm
not sure why.  Can anyone comment on this? </DanB>

o Element <num-frames> present in examples but not specified in text.
Perhaps examples should be use <utterance-length> instead?

<DanB> Yes, this is a typo.  The examples should use <utterance-length>.
</DanB>

o Section 11.5: Introduce what these two examples are supposed to be
conveying

<DanB> Good suggestion.  I'll come up with some wording.</DanB>

-----

<DanB> For all of your following comments except 11.5.6, here's my
consolidated opinion.  We have wrangled over which values belong in the
first voiceprint only for years now, and similarly for which values
belong in incremental vs. cumulative.  Additionally, the text and the
schema are not in alignment today.  Originally the goal was to have each
element only contain elements that were relevant, without redundancy,
but because different intended users of this specification have had
different ways in which they intended to fill in this info, we have
removed some options and added others.  To accommodate all of the use
cases presented over the past few years, I have the following proposal:

We permit <adapted> under only the first <voiceprint>, and make it
optional.  As in -09, it is only returned for a verification (and not
training) result.
We permit <incremental> and require <cumulative> under all <voiceprint>
elements.
Both <incremental> and <cumulative> can contain the same set of elements
under the first <voiceprint> (which I'll temporarily name "Set A"), and
both <incremental> and <cumulative> can contain the same set of elements
under all but the first <voiceprint> (which I'll temporarily name "Set
B").

Set A:
- may contain <decision>, <utterance-length>, <device>, <gender>, and
<verification-score>.  <verification-score> is required.  <decision> is
required under one or the other of <incremental> and <cumulative>, but
not both.  It is only returned for a verification (and not training)
result.  All other elements are optional under both <incremental> and
<cumulative>.

Set B:
- may contain <utterance-length>, <device>, <gender>, and
<verification-score>.  <verification-score> is required.  All other
elements are optional.

Consequences of the proposal:
- the content model is more permissive than what both the text and
schema permit in -09, except
1) it limits <decision> to only occur once in the entire result, and
that only in a verification result (as opposed to training), and
2) it requires <verification-score> under all <incremental> and
<cumulative> elements anywhere in the result.

</DanB>

o Section 11.5.3: Why is <incremental> limited to the first voiceprint?
Doesn't it make sense to have for each voiceprint (say for
identification or
multi-verification)?

o Section 11.5.4: Clarify that <decision> is not present for training
results.

o Section 11.5.x - Indicate in text which elements are required /
optional
and when.

o Section 11.5.6: Delete et-phoned-home and explain the remaining types
e.g.
what exactly is a electret-phone etc

<DanB> I agree with removing "et-phoned-home" but would not dare to
define the remaining types.  At this late date I would prefer not to
remove them, either, because of strong interest in them early on in the
discussions.
</DanB>

o Section 11.5.9: During training, is <verification-score> duplicated
under
<incremental> and <cumulative> or perhaps it should just appea
r under <cumulative>.

o Section 11.5.6 / 11.5.7: Seems like <device>, <gender> is duplicated
across <voiceprint>s for  identification / multi-verification? Is this
redundancy a known issue?

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Dave Burke" <[email-masked]>
Date: Sat, 25 Mar 2006 15:41:33 -0000

I'm OK with you proposal (I understand the need for content model 
flexibility to permit the different use-cases). However, don't we need 
<decision> under each voiceprint given the identification / 
multi-verification cases? i.e. at any given point of time there is a 
decision state associated with each voiceprint being considered?

Dave

-----Original Message-----

-----

Set A:

Set B:

</DanB>

---

From: Dan Burnett <[email-masked]>
Date: Sun, 26 Mar 2006 17:40:15 -0800 (PST)

Yes, but by the nature of verification/identification
I think we can assume that only one voiceprint will be
accepted at any given time, right?  All the others
must be rejected or unknown.

Do you have a use case that would give different
results?

--- Dave Burke <[email-masked]> wrote:

> define the remaining types.  At this late date I
> would 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Dave Burke" <[email-masked]>
Date: Mon, 27 Mar 2006 09:57:55 +0100

I was thinking of two points:

1. Even if only one voiceprint was accepted at any given time, the others 
would either be rejected or undecided and that the results ought to be 
explicit in expressing that (i.e. there would be a <decision> for each 
voiceprint). My understanding is that your proposal implies that an omitted 
<decision> is the same as <decision>rejected</decision> or 
<decision>undecided</decision>?

2. The (perhaps edge) case in  multi-verification where more than one 
voiceprint is accepted.

Dave

----- Original Message ----- 
From: "Dan Burnett" <[email-masked]>
To: "Dave Burke" <[email-masked]>; "Dan Burnett" 
<[email-masked]>; <[email-masked]>
Sent: Monday, March 27, 2006 2:40 AM
Subject: Re: [Speechsc] Consolidated comments on NLSML