Re: programaticallylocated.doc

Programmatically Located, Meanings and Pronunciations
[ Initial draft --  thinking out loud]
Problem

Currently there is a problem when reading content whenever a word, abbreviation, acronym or phrase is encountered that the reader does not know the meaning of.   If there was a way for the individual to locate the meaning of these semantics units when they occur the overall understandability of the content would be greatly enhanced.  It would also provide a mechanism for people of all reading levels to better handle content they don't understand.   Although words, phrases, jargon, foreign phrases and abbreviations appear to be very different, there is a possibility that they could all be addressed using the same strategy.

If we think of all ambiguous words, phrases, abbreviations, etc. as basically consisting of a string of characters whose meaning is unknown to the user, providing a common mechanism to look up the meaning of a string of characters would allow the reader 

If the EXACT meaning of the string of characters could be easily found (programmatically DETERMINED) , then it would be possible to provide a mechanism to automatically determine the meaning of the string.   Doing so however would require that the specific meanings of many words would have to be individually marked.  A simpler task would be to provide the user with a list of possible meanings for the string. Although, this is not as useful as being able to point to the exact, correct meaning, it still would be of great benefit. In addition, in many cases, the string would be unique and so the mechanism to 'programmatically locate' the meaning would by default, be a mechanism to determine the exact meaning. For example, a common foreign phrase, such as "c'est la vie". 

Proposal

It is proposed that a mechanism based on reverse-cascading dictionaries be defined that would allow user agents to quickly locate the definitions of words or phrases (character strings) specified by the user. 

In practice, an author would specify a list of cascading dictionaries that should be used with particular page, or section of a website, or website. This could be done by either embedding an ordered list of dictionaries in meta-data associated with the page itself, or by putting an ordered list in a specific document (e.g., dictionaries.html) at the root of the URI for the page (or at any apparent level of the URI).  For example the dictionary for the web page  www.mycomp.com/docs/sales/plan/easternplan.html  could be located at www.mycomp.com/dictionaries.html. 

Once the user agent has fetched the ordered list of dictionaries, it would search for the word, starting at the highest level of the dictionary and then working through the cascade.  For speed, simultaneous queries could be made to all, or if they were on a single site, a compound request might be issued. The definition presented to the user would be either the one in the most "local" dictionary or the results could be presented to the user with the most "local" dictionary definitions presented first. 

By using cascading dictionaries, the meanings of abbreviations or acronyms can be defined differently for different pages or different areas of a website.

The user experience

To the user, this might look like an individual right-clicking on a word, (or highlighting a phrase and right-clicking on it) and selecting "dictionary" or "meaning" or "look-up" from the drop-down menu. The user agent would then provide a results display of some type, with the meaning(s) of the word or phrase displayed. For different types of user agents, different mechanisms could be used to provide an equivalent functionality appropriate to the medium being used (visual, auditory, etc.)

(The right-click menu could also provide opportunities for the individual to look up the meaning or symbolic or other forms, if they are available or if a converter was available to turn the text into symbols.) 

Author experience

For a page to qualify as meeting the success criteria dealing with "programmatically locatable", it would be necessary to have all of the words or phrases in the document be programmatically locatable.    An author would start by simply associating some major online dictionary with the page using their author tool. Immediately, most of the words in the document, would be covered, and only those words that were not in the dictionary would be highlighted and provided in a list to the side. The author would then associate any other dictionaries that were common to the type of material that they were generating (e.g., they might associate a medical dictionary if they were using a lot of medical terms, or they might associate a W3C glossary if they were using a lot of web terms). Instantly, all of those terms would disappear from the "un-locatable" listing. Authors would usually have two or three dictionaries or glossaries that they commonly used with their content.  In addition, a company may maintain a dictionry of its own that it uses frequently or terms that it has defined itself.  In order for a page to qualify,  it is not necessary for proper names to be locatable,. However, companies may want to provide a short description to their product names as well as their jargon.  By attaching this list to the "local" end of the cascade, they can make it easy for individuals to find those definitions, understand those terms, identify those products or get the proper expansion for an acronym that has many different definitions in different fields. 

If the website has a set of cascading dictionaries at its root, then the author may find that all of the words on the page are already "locatable" without them doing anything at all. If there is a peculiar word on the single page, it is also possible for the author to put a set of dictionary words directly inside the page. 

Implementation Techniques (Programmatically located)
Handling dictionaries with different query formats

It would be good if there was a standard mechanism for the dictionary so that a simple command with the source string could be sent to any of the URIs and it would return the block of text for that term. 

However, URIs having different search query forms could still be used. The URI in the document would simply take the form of the full URI, including the query text with a placeholder where the word or phrase to be searched would be inserted. Thus, a set of cascading URIs could access a set of cascading dictionaries, each of which had a different query form. They would do it by simply including the query form in the list of URIs.  

http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=<string>
http://www.encyclopedia.com/searchpool.asp?target=%22<string>%22 
Alternate ways of associating the list of dictionaries with the content

Content may not always be of a form that it is easy to attach other information. A number of methods might therefore, be used. Some were described above. Another might be to have a page with the cascading dictionary list at the same URI, except the ending would be some standard ending, say ".dict".

In the end, we probably do not want to have a million different formats and options. However, we should have a selection of options that are very robust and allow the author to be able to handle the full range of web content types. 



----- Messaggio originale -----
    Da: "Charles McCathieNevile"<charles@sidar.org>
    Inviato: 07/08/04 4.45.18
    A: "Gregg Vanderheiden (by way of Al Gilman)"<gv@trace.wisc.edu>, "wai-xtech@w3.org"<wai-xtech@w3.org>
    Oggetto: Re: programaticallylocated.doc
    
    
    Could someone please send this in text form? Please note W3C's guidelines  
    on attachment formats:
    
    http://www.w3.org/2002/03/email_attachment_formats.html
    
    [[
    Avoid unnecessary email attachments.  Use an attachment only when it is  
    likely to benefit to recipients. Otherwise, place the information (in  
    plain text format) in the body of your message.
    If an attachment is necessary, avoid formats that are virus prone,  
    proprietary or platform dependent.  For example, whenever possible you  
    should use HTML instead of MS Word, PowerPoint or PDF.  (Ideally, use  
    XHTML or HTML4.)
    If you must use a proprietary or platform-dependent format, please also  
    include an alternate version in  a universally readable format, such as  
    HTML or plain text, if possible. If you cannot, then at least include a  
    format that has widely available free viewers, if possible.
    ]]
    
    cheers
    
    Chaals
    
    On Fri, 6 Aug 2004 22:15:42 -0400, Gregg Vanderheiden <gv@trace.wisc.edu>  
    wrote:
    
    > Would you send this to the right people
    >
    > This is for part of our discussion next week.  [joint session
    > WCAG:PF:SW et_al -- Al]
    >
    > Thanks
    >
    > Gregg
    >
    
    
    
    -- 
    Charles McCathieNevile         charles@sidar.org
    Fundación Sidar             http://www.sidar.org
    
    
    

[Messaggio troncato. Toccare Modifica->Segna per il download per recuperare la restante parte.]

Received on Saturday, 7 August 2004 08:20:29 UTC