W3C home > Mailing lists > Public > w3c-wai-hc@w3.org > October to December 1997

Re: phonetic markup

From: Al Gilman <asgilman@access.digex.net>
Date: Fri, 7 Nov 1997 15:31:14 -0500 (EST)
Message-Id: <199711072031.PAA13013@access5.digex.net>
To: w3c-wai-hc@w3.org (HC team)
to follow up on what Masafumi
NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= said:

> Hi,
> 
> Thanks for the comment.
> 
>      > Use of IPA is a possibility in phonetic data; SGML attributes
>      > cannot be user-typed to indicate LANG or encoding on the fly.  So
>      > we may need another, richer mechanism for binding phonetic
>      > equivalents to standard text.
> 
> Actually, I thought about using IPA.  I think there are several points 
> to consider:
> 
> 1. Is IPA good enough to present pronunciation of any language?
> 

No.  But lots of languages.  It is an existing standard that we should
use but not limit ourselves to.  The phonologists (phoneticists?) will
always have a few more sounds that are used in Tlingit or 'Kung or
something like that. 

> 2. How should the supplied IPA be treated?
> 
> Since most of the voice synthesizer (as far as I know all of them) can 
> just handle phonetic codes of certain language, ie, English aplphabet, 
> Japanese kana, etc., there should be some pre-processing to the
> supplied IPA string before passing it to the voice synthesizer.  This
> can, of course, be soved if the voice sythesizer vendors start
> supporting IPA in their hardware.
> 
> 3. Will people use IPA to provide phonetic information?
> 
> I think people don't bother to use this mechanism unless it is
> relatively easy for them to write the phonetic representation.  So in
> the case with Japanese, kana is widely used and well-known, while IPA
> is rarely seen by people except when they look up English-Japanese
> dictionaries, so that there would be more probability that the
> Japanese use this mechanism if kana could be used.
> 

My suspicion here is that because IPA is adequate for covering
most indo-european languages it will be easier to get dictionary
and synthesizer vendors to support it than some other phonetic
dictionary.  The average users will perhaps fill in pronunciation
by either a dialog box or an audio dialog.  The point is that the
system will code what it learns in some phonetic format, play it
back, and the user won't accept it until it is right.  IPA is the
cheap and easy phonetic markup.  There is a whole wing of the
Internet Internationalization community working on phonetic data
formats.  We just need to make sure that we don't assume just one
at this time.

But we should ask them.

For Japanese you don't need IPA because you already have a fully
phonetic script in the kana.  Japanese is unusual that way.

I know of no other language which is written as phonetically as
Japanese (outside the use of Kanji which of course are
ideographs).  Spanish is more phonetic than English but Japanese
is the tops in pronounceability off the page.

> 
>      > There are at least three ways to go to connect the phonetic script
>      > and the text web-content:
> 
>      > one:  HTML attribute as you suggested
> 
> I guess this is the simplest one and easiest one to understand, thus
> my suggestion.
> 
>      > two:  CSS attribute targetted to audio medium (applied via inline style)
> 
> At this point, I need to put much more effort to read the CSS2 spec to 
> fully understand this.
> 
>      > three:  Dictionary entry with proper noun marked as "must see
>      > dictionary for pronunciation."  Dictionary linking via LINK attribute
>      > and/or RDF.
> 
> Yes.  Maybe this will solve most of the cases.  But would this
> approach solve problems like in examples [2a and [2b] in my memo?

It can, but it takes help from markup in the document or attached
to the document to resolve these cases.  The LINK and META
extension proposal (REF topic) was to force HTML to provide the
capability directly, but in the end we decided on a leap of faith
and try to make it work with RDF, so we withdrew that request
from HTML.

> (Sorry, I haven't had time to read and understand what RDF can
> do, so I may be wrong.)

Hey, you are doing great so far.

RDF is a moving target.  We have a "long-term" work item to
partner with the metadata group to make sure that when it stops
moving it can do what we need.

You are being clear about the function needed.  That is what RDF
needs us to help them with.  They can trade off options for how
to implement it if the need is clear.

-- Al
Received on Friday, 7 November 1997 15:31:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:11 UTC