Re: SpeechRecognitionAlternative.interpretation when interpretation can't be provided

Checking for type string isn't sufficient to determine that a SISR tag
wasn't used, since you can return strings from SISR IIRC.

On Thu, Aug 16, 2012 at 2:29 PM, Glen Shires <gshires@google.com> wrote:
> Yes, the developer has control over what values are returned ... except when
> they're not returned.
>
> It's easier to check for undefined than check for type string.
> I agree that it's not a big deal either way "for the typical way this would
> be used", however if the developer wanted to do something else, it may be
> more complex (check type for a string, check that both strings match, etc).
>
> Seems to me that undefined is a little simpler in some cases, and a lot
> simpler in other cases.
>
> /Glen Shires
>
> On Thu, Aug 16, 2012 at 6:24 AM, Bjorn Bringert <bringert@google.com> wrote:
>>
>> The interpretation typically comes from SISR tags that the developer
>> has written. So the developer has control over what values are
>> returned and when.
>>
>> Also, as you mention, the typical way this would be used would be to
>> use "transcript" if "interpretation" is empty. Putting the text in
>> "interpretation" does that for you.
>>
>> It's not a big deal either way though I think.
>>
>> On Thu, Aug 16, 2012 at 2:20 PM, Glen Shires <gshires@google.com> wrote:
>> > I propose that last sentence be replaced by "If no semantic meaning can
>> > be
>> > determined, the attribute must return 'undefined'."
>> >
>> > The reason being that this simplifies the developer's coding. The
>> > interpretation attribute is of type "any" because it typically returns
>> > structured data.
>> >
>> > 'undefined' allows the developer to perform a simple check to determine
>> > if
>> > the interpretation is present, and if not, simply use the transcript
>> > attribute, which is always a string.
>> >
>> > Conversely, the developer would have to check for the type of the
>> > object(s)
>> > returned in the interpretation attribute, requiring significantly more
>> > complex code.
>> >
>> > /Glen Shires
>> >
>> >
>> > On Thu, Aug 16, 2012 at 5:58 AM, Hans Wennborg <hwennborg@google.com>
>> > wrote:
>> >>
>> >> Yes, the raw text is in the 'transcript' attribute.
>> >>
>> >> The description of 'interpretation' is currently: "The interpretation
>> >> represents the semantic meaning from what the user said. This might be
>> >> determined, for instance, through the SISR specification of semantics
>> >> in a grammar."
>> >>
>> >> I propose that we change it to "The interpretation represents the
>> >> semantic meaning from what the user said. This might be determined,
>> >> for instance, through the SISR specification of semantics in a
>> >> grammar. If no semantic meaning can be determined, the attribute must
>> >> be a string with the same value as the 'transcript' attribute."
>> >>
>> >> Does that sound good to everyone? If there are no objections, I'll
>> >> make the change to the draft next week.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Wed, Aug 15, 2012 at 5:29 PM, Conversational
>> >> <dahl@conversational-technologies.com> wrote:
>> >> > I can't check the spec right now, but I assume there's already an
>> >> > attribute that currently is defined to contain the raw text. So I
>> >> > think we
>> >> > could say that if there's no interpretation the value of the
>> >> > interpretation
>> >> > attribute would be the same as the value of the "raw string"
>> >> > attribute,
>> >> >
>> >> > Sent from my iPhone
>> >> >
>> >> > On Aug 15, 2012, at 9:57 AM, Hans Wennborg <hwennborg@google.com>
>> >> > wrote:
>> >> >
>> >> >> OK, that would work I suppose.
>> >> >>
>> >> >> What would the spec text look like? Something like "[...] If no
>> >> >> semantic meaning can be determined, the attribute will a string
>> >> >> representing the raw words that the user spoke."?
>> >> >>
>> >> >> On Wed, Aug 15, 2012 at 2:24 PM, Bjorn Bringert
>> >> >> <bringert@google.com>
>> >> >> wrote:
>> >> >>> Yeah, that would be my preference too.
>> >> >>>
>> >> >>> On Wed, Aug 15, 2012 at 2:19 PM, Conversational
>> >> >>> <dahl@conversational-technologies.com> wrote:
>> >> >>>> If there isn't an interpretation I think it would make the most
>> >> >>>> sense
>> >> >>>> for the attribute to contain the literal string result. I believe
>> >> >>>> this is
>> >> >>>> what happens in VoiceXML.
>> >> >>>>
>> >> >>>>> My question is: for implementations that cannot provide an
>> >> >>>>> interpretation, what should the attribute's value be? null?
>> >> >>>>> undefined?
>> >>
>> >
>>
>>
>>
>> --
>> Bjorn Bringert
>> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
>> Palace Road, London, SW1W 9TQ
>> Registered in England Number: 3977902
>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Received on Thursday, 16 August 2012 13:49:41 UTC