- From: Arun Kumar <kkarun@in.ibm.com>
- Date: Wed, 23 Sep 2009 15:58:03 +0530
- To: Stephane Boyera <boyera@w3.org>
- Cc: public-mw4d@w3.org
Thanks very much Stephane for summarizing the discussion in your response.
I apologize again for not being able to make it for the last call else this
iteration would not have been required.
Please read along for my responses.
> A. Access Challenges: Accessibility [Section 6.1.1]
>> is it just a wording issue and removing the 'as equally' would be
enough ?
<AK> Yes, I guess, it is just a wording issue. I wanted to make sure that
the problem of accessibility is realized as being *more severe* in
developing countries than in developed countries since technology and
devices to aid the needy is available and accessible to people in developed
countries. The document seems to reflects the opposite as of now.
</AK>
> B. Costs [Section 6.1.5]
>>. Right; The current situation is ..........this may change in a near
future. Would that answer your comment ?
<AK> Sure. That is fine. </AK>
> 1)
> A major challenge.......>
>> right. i'm happy to mention this as a side note. This is not a
characteristic of the technology, but just >>an extra layer on top of it,
in same way as CMS, blog engines and so on. Moreover, this falls in the
>>category of mobile as an authoring platform which has been considered out
of the scope of this document.
>>so i propose to mention that as note in the section. Would that be ok
with you ?
<AK> Not sure whether I understand the implications here. Basically, I
would consider the mentioned advances in voice application creation as
improvement in technology and not really a layer in the same layer as CMS
and Blogs. The reason for that is that such a platform is parallel to
existing web application frameworks and allows users to create their own
apps such as CMS, Blogs, Wikis and many others. So, if one considers the
web application frameworks (Ruby on Rails, Struts etc.) in vogue today as
technology then a voice application creation framework probably qualifies
as one too. Though I would admit that it is not yet freely available but
its use is increasing and slowly opening up.
If it falls outside of the scope of the document, it is fine to move this
point into a note. But the weakness of voice as a platform owing to
expertise required needs to be diluted as development of such apps is now
not restricted to programmers and computer scientists. This would help
avoid the readers from turning away from this promising mode of offering
services.
Hope, I could clarify.
</AK>
>2) A concern related to .........technologies for Voice applications
mature.
>>for me this is more a hack around the technology to fix an issue rather
than a feature.
>>Moreover, with voicexml applications it is very easy to build portals and
create links to third parties >>applications. this is far harder with
traditionnal voice apps which would require call transfer to another
>>numero, which is far more tricky to implement. So in conclusion, i'm
happy to add a bit that mention the fact >>that portals are possible and
easy to do with voicexml, possible with voice apps, but there is no
built-in >>discoverability features. would that be ok with you ?
<AK> I think I understand what you mean. If I got you correctly, the point
is that VoiceXML (or other voice application technologies) does not provide
support for including meta information for discoverability. While this may
be true, it is independent of whether services are discoverable since the
mechanism to do that might exist outside of the authoring technology.
I would again draw the comparison with how search evolved in the Web, where
the static and dynamic websites themselves did not have much information
but then the search engines developed crawling and indexing schemes outside
of the web authoring technology itself. It was only later that XML and then
Semantic Web approaches came into being to be able to specify structural
meta-information and semantic information respectively. So, while the core
voice app authoring technology (vxml) may not have discoverability but it
probably is not accurate to consider the mechanisms outside of it as
workarounds.
</AK>
>3)
> Another issue mentioned is that ...........themselves are captured and
automatically made available on the VoiceSite.
>> i believe there are two aspects:
>>1- the ability to access and reuse an answer without interacting again
with the service
>>2- the ability to access previous results.
>> i'm only talking about the point 1. here, while sms are automatically
stored in the phone of the users, or >>while web pages are cached in the
browser, the information received through a voice call is transient for
>>the user. It is possible at the application level to implement a
workaround through e.g. droppin the result >>of the query to an sms or as a
voicemail msg in the user voicemail box, but this is not handled at the
>>technology level. I propose to mention that. would that be ok with you ?
<AK> I agree with your split of the two issues and that they need to be
dealt with separately. To add further clarification, SMS is a store and
forward technology that requires first storing the message at intermediate
locations before forwarding it further on the route to destination (similar
to emails).
In contrast, dynamic web applications as well as dynamic voice applications
are online content delivery technologies and storage of content delivered
is not inherently built into the core technology for both. This is
exemplified in your example of cached content in web browser. It needs an
external component (cache in a browser which is at client site and
independent of the dynamic application at server side) to support offline
content storage in the online web world. This is also limited since dynamic
content site such as those delivering weather status or stock quotes cannot
benefit much from this. The static content can either be cached by browser
at its own will (i.e. subject to cache size on disk and cache management
policies) or explicitly saved by the end user.
Similar strategy as for online web applications works for voice
applications as well. It is just that investment has to be made into
building client specific technology equivalent to Web Browsers that can
cache content or allow users to save a snapshot of the online content and
browse it in offline mode, if needed.
Two examples of such technology that are moving in this direction are (1)
Literacy Bridge (http://www.literacybridge.org/ ) where a low -cost device
allows recording and playing of audio as well as provides navigational
features for easy retrieval and knowledge sharing. I met its executive
director Cliff Schmidt earlier this year who informed me that adding
support for telephony content is a small extension to their device.
Second example in the making is from the Spoken Web project and called
World Wide Telecom Web Browser (http://www2008.org/papers/pp147.html )
whose aim is to be the voice web equivalent of web browsers with
functionality such as navigation across voice applications, bookmarks, etc.
To summarize, I personally feel that it is a technology that is waiting to
be developed. Hope, I could convince you :-)
</AK>
BTW, the effort that has gone into the document is appreciable and it is
turning into a good reference source.
thanks and regards
Arun Kumar
http://www.research.ibm.com/people/a/arun
Stephane Boyera
<boyera@w3.org>
Sent by: To
public-mw4d-reque Arun Kumar/India/IBM@IBMIN
st@w3.org cc
public-mw4d@w3.org
Subject
09/22/2009 03:05 Re: Feedback on Roadmap
PM
Hi Arun,
we discussed your comments yesterday and i wanted to share with you the
proposed resolutions to see if they fit you before i proceed to the
implementation in the document.
> A. Access Challenges: Accessibility [Section 6.1.1]
>
> The first paragraph mentions that Accessibility is at least as equally
> critical in Developing Countries as in Developed Countries. The WHO
> reference about Visually Impaired people in developing countries that
> follows in the next statement, however, suggests that the problem of
> accessibility is probably more severe in Developing Countries. Reasons
> include un-affordability of expensive assistive devices and technologies,
> non-english speaking population and illiteracy etc. Further, as in the
> visually impaired case referred above, a bulk of population needing but
> deprived of such technologies reside in developing countries.
We were not sure to understand the essence of this comment; is it just a
wording issue and removing the 'as equally' would be enough ? or are you
proposing something else ?
i think we all agree to emphasis on this issue, and it might indeed to
be really useful to compare it with developed countries, but if you have
something else in mind let us know.
> B . Costs [Section 6.1.5]
>
> It is mentioned that Voice applications use the voice channel and it is
> costliest as the charges are based upon the length of the call. With the
> innovative strategies and value-adds that several telecom operators are
> coming up with, this may not longer remain an issue. For instance, a
couple
> of major telecom providers (especially Reliance communications) in India
> offer free calls to either a limited set of phone numbers or to callers
> within the same telco's network or during non-peak hours (such as in the
> night).
>
> http://www.efytimes.com/e1/fullnews.asp?edid=19268
> http://www.efytimes.com/e1/fullnews.asp?edid=15716
>
> Most recently, another operator - Tata Indicom, has started offering
> pay-per-call charging model, making call charges free of per-minute rate.
>
http://teck.in/pay-per-call-prepaid-plan-of-tata-indicom-and-tata-teleservices.html
Right; The current situation is that the costs of voice communication is
high, and is a barrier for most potential users. Moreover, the quantity
of information conveyed by voice applications for a specific amount of
time is far lower than for other technologies. So, as of today, the
costs for the user is the highest for voice apps. However, your examples
demonstrats that this might change in the future, and like for data
services, there might be free/cheap flat rate plan for voice call in the
future. This is just perhaps a matter of regulation and/or competitions.
So i propose to add this in the document, stating that this is the case
for now, but there are evidences that this may change in a near future.
would that answer your comment ?
> 1)
> A major challenge listed in the Weakness of Voice Applications
sub-section
> is related to expertise required for building voice applications, i.e.
> expertise required to use voice modality on mobiles to provide an
authoring
> platform. As rightly mentioned in the roadmap, authoring of a voice
> application has not been an easy task. However, the state-of-the-art here
> has already advanced. This should probably be reflected in the document.
> Using the Spoken Web system (mentioned in Examples in Section 7.1),
> ordinary phone subscribers can create their own Voice applications in a
> matter or few minutes. These voice application creators can be non-IT
> literate or even completely illiterate and can create the applications in
> their own local language using an ordinary lowest end mobile phone.
>
> More details on the system are available in the articles mentioned below
> and I would be happy to give a 15-20 min. live demo of VoiceSite creation
> technology in the next conference call, if there is interest.
>
> [a] VOISERV: Creation and Delivery of Converged Services through Voice
for
> Emerging Economies
>
https://domino.research.ibm.com/comm/research_people.nsf/pages/arun_kumar.pubs.html/$FILE/VOISERV-IEEE-WowMom2007.pdf
..
>
>
> [b] VoiKiosk : Content Creation and Dissemination by-and-for Users in
Rural
> Areas
>
>
>
http://mobileactive.org/research/voikiosk-content-creation-and-dissemination-and-users-rural-areas
>
> [c] FOLKSOMAPS - Towards Community Driven Intelligent Maps for Developing
> Regions
>
>
http://www.researchintouse.com/downloads/spokenweb/Folksomaps_-_ICTD_09_-_April_09.pdf
..
right. i'm happy to mention this as a side note. This is not a
characteristic of the technology, but just an extra layer on top of it,
in same way as CMS, blog engines and so on. Moreover, this falls in the
category of mobile as an authoring platform which has been considered
out of the scope of this document.
so i propose to mention that as note in the section. Would that be ok
with you ?
> 2)
> A concern related to user issues is the challenge of discoverability of
> voice applications. While complete automated indexing of voice
applications
> and search is still in its infancy, it is also not impossible for someone
> to discover available services offered as voice applications. Manually or
> semi-automatically created directories could provide phone numbers of
> various businesses registered with them. This could be done either
through
> call center operations as in http://www.JustDial.com or through voice
> search as being done by Ubona (
>
http://www.webyantra.net/2007/11/08/ubonavoice-search-engine-for-bangalore/
> ) and GOOG-4-1-1 (http://www.google.com/goog411/ ). Here, the phone
> numbers returned would actually represent voice applications deployed
> against them.
>
> Such directory services can very well be used for discoverability of
voice
> applications. This is similar to the initial pre-search engine days of
the
> web when online sources such as Yahoo Directory containing categorized
> content represented the primary source of discovering information on the
> web. So, directories can serve the purpose of discoverability while
search
> technologies for Voice applications mature.
for me this is more a hack around the technology to fix an issue rather
than a feature.
Moreover, with voicexml applications it is very easy to build portals
and create links to third parties applications. this is far harder with
traditionnal voice apps which would require call transfer to another
numero, which is far more tricky to implement.
So in conclusion, i'm happy to add a bit that mention the fact that
portals are possible and easy to do with voicexml, possible with voice
apps, but there is no built-in discoverability features. would that be
ok with you ?
>
>
> 3)
> Another issue mentioned is that the lifetime of the information is short
> and cannot be stored and shared. Technologically it is not difficult to
> provide. I believe such applications are not in vogue only because
> businesses and other organizations have not yet realized the need to
> explore the use of such means. This is changing too. For instance, in an
> ongoing commercial pilot described at
> http://hci.stanford.edu/research/otalo/ , Development Support Center
(DSC)
> - an NGO in Western Indian state of Gujarat runs a bi-weekly community
> radio program about Agricultural best practices. It has an estimated
> viewership of 5,00,000 farmers. It makes use of a VoiceSite (a voice
> application in Spoken Web) that acts as a complimentary feedback channel
> for the radio program and also serves as an archive of those radio
programs
> to be listened to later (by calling up the VoiceSite). In addition,
expert
> advice given to farmers, questions asked by others as well as discussion
> threads among farmers themselves are captured and automatically made
> available on the VoiceSite.
i believe there are two aspects:
1- the ability to access and reuse an answer without interacting again
with the service
2- the ability to access previous results.
i'm only talking about the point 1. here, while sms are automatically
stored in the phone of the users, or while web pages are cached in the
browser, the information received through a voice call is transient for
the user. It is possible at the application level to implement a
workaround through e.g. droppin the result of the query to an sms or as
a voicemail msg in the user voicemail box, but this is not handled at
the technology level. I propose to mention that. would that be ok with
you ?
> 4)
> I agree with the suggestion in Future Directions subsection, that hosting
> services similar to Tell Me are needed for large scale deployment of
Voice
> applications. Along with that we also need packaged software/hardware
> 'appliances' to let individuals setup their own low scale voice
application
> creation and hosting using desktop PCs and a couple of incoming phone
> lines.*
this is very good point. I very briefly mentionned it in section 6.2.3
but i will add some words in the voice sections, as this is a very
important points. it should appears also in the support actions*
Thanks a gain for your comments, and please let us know how you feel
about these answers
cheers
Stephane
>
>
> thanks and regards
> Arun Kumar
> IBM Research - India
> kkarun@in.ibm.com
>
> Spoken Web (aka World Wide Telecom Web) :
>
http://domino.research.ibm.com/comm/research_people.nsf/pages/arun_kumar.WWTW.html
>
> "Websites that use the spoken word will empower the illiterate" -
> (
http://www.economist.com/sciencetechnology/displaystory.cfm?story_id=13855374.
> )
>
>
>
>
--
Stephane Boyera stephane@w3.org
W3C +33 (0) 5 61 86 13 08
BP 93 fax: +33 (0) 4 92 38 78 22
F-06902 Sophia Antipolis Cedex,
France
Received on Wednesday, 23 September 2009 11:12:57 UTC