RE: Some prioritization

Bjorn,

In our charter, we agreed to provide a "high quality" and "browser independent" experience.  Although I think your idea is clever and perhaps the future of search, it falls short on both of these objectives.

Moving existing speech customers to a generic language model with generic parameters is a recipe for disaster.  Furthermore, since the accuracy of the speech interaction would vary significantly from browser to browser, it could not be characterized as a browser-independent experience.

- Milan


-----Original Message-----
From: Bjorn Bringert [mailto:bringert@google.com] 
Sent: Friday, January 14, 2011 2:18 PM
To: Robert Brown
Cc: Young, Milan; Olli@pettay.fi; public-xg-htmlspeech@w3.org
Subject: Re: Some prioritization

Ah, so you are saying that all *valuable* speech web apps will need a
web-app specified recognizer (and a lot of development resources). And
I'm saying that the majority of *all* the web apps that use speech
will use the default speech recognizer. The conclusion then is that
the majority of speech web apps will not be valuable :-)

There is an alternative: the default speech recognizer could
automatically adapt its base language model to each web app, based on
the speech input that it has gotten from all users of that web app.
That would mean a constant quality improvement, with no effort from
the web developer or the user. It would sacrifice some developer
control though.

/Bjorn

On Fri, Jan 14, 2011 at 9:54 PM, Robert Brown
<Robert.Brown@microsoft.com> wrote:
> I'm pretty sure I'm saying the opposite :)
>
> I'm saying is that I don't think you can build valuable speech apps without specialized skills or carefully selected technology.
>
> Sure, for simple control, any modern recognizer should be fine.
>
> But for most of the use cases you've listed (search, messaging, dictation, translation), the developer definitely cares what n-grams are being used, what trained them, the nuances of the recognizer that'll generate the results, and how I make my ngram available to the service provider.  E.g. If I'm a web site that provides a large catalog of movies for people to watch (Netflix, Hulu, Amazon, etc) I definitely care what training data went into the SLM, and I definitely care about tuning to the confidence of the particular recognizer I'm using, and the commercial & service terms under which I share my n-gram with the vendor providing the recognition service.
>
>
> -----Original Message-----
> From: Bjorn Bringert [mailto:bringert@google.com]
> Sent: Friday, January 14, 2011 1:43 PM
> To: Young, Milan
> Cc: Robert Brown; Olli@pettay.fi; public-xg-htmlspeech@w3.org
> Subject: Re: Some prioritization
>
> Robert: So you are saying that few organizations have the resources to build apps that need to use a specific speech recognizer? Doesn't that mean that most organizations, and thus most web apps, will not need to use a specific speech recognizer?
>
> Milan: The use cases that I listed (search, messaging, dictation, translation, simple control) have plenty of commercial applications.
> They should work ok with a high-quality default speech recognizer.
>
> I'm not denying the value in web-app specified speech services. I'm just saying that there are important use cases for default speech services, and that I believe that those are the ones that will give the most immediate benefit: making it possible for millions of web developers to easily create speech applications.
>
> I think that within the incubator group, we have different priorities for default vs web-app specified speech services. It doesn't seem like discussion is likely to change that. One possible outcome is that we work on two proposals, one for default speech services and one for web-app specified speech services, and allow them to move ahead at different pace depending on support from browser vendors etc. I have no idea whether that would be a good way to work though.
>
> /Bjorn
>
> On Fri, Jan 14, 2011 at 7:16 PM, Young, Milan <Milan.Young@nuance.com> wrote:
>> I agree with Robert.  If folks want to tinker with Voice systems, there are plenty of GUI tools and free services to get them started.
>>
>> I've taken it as a given that commercial applications (like the Google search demo) would be in a V1 release.  That's not possible in a portable manner without an application-specified network recognizer.
>>
>>
>> -----Original Message-----
>> From: Robert Brown [mailto:Robert.Brown@microsoft.com]
>> Sent: Friday, January 14, 2011 10:09 AM
>> To: Bjorn Bringert; Olli@pettay.fi
>> Cc: Young, Milan; public-xg-htmlspeech@w3.org
>> Subject: RE: Some prioritization
>>
>> I suspect the opposite is true.  The hardest part of speech development is grammar/SLM design & tuning, and few organizations have the expertise to do a good job there.  Those that do, will optimize around a specific service.
>>
>> -----Original Message-----
>> From: public-xg-htmlspeech-request@w3.org
>> [mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Bjorn
>> Bringert
>> Sent: Friday, January 14, 2011 3:20 AM
>> To: Olli@pettay.fi
>> Cc: Young, Milan; public-xg-htmlspeech@w3.org
>> Subject: Re: Some prioritization
>>
>> On Fri, Jan 14, 2011 at 11:05 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
>>> On 01/13/2011 07:59 PM, Young, Milan wrote:
>>>>
>>>> Hello Olli,
>>>>
>>>> I'd be interested to know what sort of use case you have in mind
>>>> that uses default speech services.
>>>
>>> I was mainly thinking about rather simple speech interfaces created
>>> by individual web developers who want to try out new features.
>>> I would assume grammars created by them aren't that big.
>>> We really want comments about the API from the web developers.
>>>
>>> Also things like speech-enabled web search should be doable, and
>>> message (email/twitter/sms) dictation.
>>>
>>> And speech enabled controls in a web page.
>>> "Go to the next article", "Read this article", etc.
>>>
>>>
>>>>  I have been under the impression that most real world apps have
>>>> grammars that are either too large or too sensitive to be
>>>> transported over the network.
>>>
>>> Well, there are no real world speech enabled web apps commonly
>>> available, so we don't necessarily know what they will look like ;)
>>> But sure, for many cases (complex dialogs, specialized search, etc.)
>>> network engines would be need.
>>
>> I agree that default speech services are very important. Use cases that could be handled pretty well include search, messaging, dictation, translation, simple control. I think that the majority of speech web apps (as measured in number of apps) will use default speech services, because the developers do not have the resources to run their own speech services. I also think that this will account for the majority of the speech app usage, at least in the beginning.
>>
>> If simple speech web apps take off, I think that we will see a gradual increase in interest in more complex applications and in interest from organizations large enough to devote resources to running their own high-quality speech services.
>>
>> /Bjorn
>>
>>>> -----Original Message-----
>>>> From: public-xg-htmlspeech-request@w3.org
>>>> [mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Olli
>>>> Pettay
>>>> Sent: Thursday, January 13, 2011 7:14 AM
>>>> To: public-xg-htmlspeech@w3.org
>>>> Subject: Some prioritization
>>>>
>>>> Hi all,
>>>>
>>>> I may not be able to attend conference call today (if we have such).
>>>> But anyway, I started to prioritize requirements the way I think
>>>> about them. Or more so, I picked up lower priority requirements and
>>>> categorized them to 3 groups.
>>>> I don't know how we're going to prioritize requirements, but I guess
>>>> it doesn't harm to send this kind of email so that you know what
>>>> kind of specification proposal I'm expected to see later this year.
>>>>
>>>>
>>>> -------------
>>>> A bit lower priority:
>>>> FPR46. Web apps should be able to specify which voice is used for TTS.
>>>> FPR57. Web applications must be able to request recognition based on
>>>> previously sent audio.
>>>>
>>>>
>>>> -------------
>>>> Low priority:
>>>> FPR28. Speech recognition implementations should be allowed to fire
>>>> implementation specific events.
>>>> FPR31. User agents and speech services may agree to use alternate
>>>> protocols for communication.
>>>> FPR48. Web application author must be able to specify a domain
>>>> specific statistical language model.
>>>> FPR56. Web applications must be able to request NL interpretation
>>>> based only on text input (no audio sent).
>>>>
>>>>
>>>> -------------
>>>> Something perhaps for V2 specification These requirements can be
>>>> important, but to get at least something done soon we could perhaps
>>>> leave these out from v1 specification.
>>>> Note, v2 specification could be developed simultaneously with v1.
>>>>
>>>> FPR7. Web apps should be able to request speech service different
>>>> from default.
>>>> ...and because of that also the following requirements FPR11. If the
>>>> web apps specify speech services, it should be possible to
>>>>
>>>> specify parameters.
>>>> FPR12. Speech services that can be specified by web apps must
>>>> include network speech services.
>>>> FPR27. Speech recognition implementations should be allowed to add
>>>> implementation specific information to speech recognition results.
>>>> FPR30. Web applications must be allowed at least one form of
>>>> communication with a particular speech service that is supported in
>>>> all UAs FPR33. There should be at least one mandatory-to-support
>>>> codec that isn't encumbered with IP issues and has sufficient
>>>> fidelity&  low bandwidth requirements.
>>>> FPR55. Web application must be able to encrypt communications to
>>>> remote speech service.
>>>> FPR58. Web application and speech services must have a means of
>>>> binding session information to communications.
>>>>
>>>>
>>>>
>>>>
>>>> -Olli
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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
>
>



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

Received on Saturday, 15 January 2011 01:34:29 UTC