Re: How to describe Flowcharts, Schematics, etc

   
Hello Len, Charles, Dave, Karl etal:
Charles:
">...the HTML/XML world there are a couple of predefined relationships based on a
>particular structure - the tree structure which defines parent, child and
>sibling relationships, and in HTML there is also a link between two anchored
>points. In the HTML linking mechanism there is a rel and a rev attribute
>which can be used to define arbitrary types of relationship - for example
>that one end of  the link is a stylesheet for the other, or that one end of a
>link is the next document in a sequence. ..."
Thanks for pointing this out, Charles, I was not aware of the full facilities in this regard.

Len:
">...Imagine what happens if the diagram is a lot larger.  Assuming the diagram
>is drawn clearly and isn't much too large, a sighted person can quickly
>answer:
>
>1. Is there a single animal at the top of the food chain?
>2. Are there any animals that eat each other?
>3. What animals eat lots of things?
>4. Does the diagram have food loops where the last one comes around and 
>    eats the first, e.g. human eats chicken eats mosquito eats human eats
>chicken etc...
>
>In principle, a determined blind user can figure this out by walking around
>the tree, but there should be facilities to make it easier.  That's why in
>addition to having an underlying abstract representation, we need tools to
>conveniently answer questions such as the above.  ..."

Thanks, Len, for this  wonderful example and general conclusions based on it.  This expresses my thoughts more precisely than I did.  

">Actually, it goes beyond this.  The user shouldn't even have to think of
>the questions.  The program should identify "interesting" relations and
>point them out to the user.  In other words the program would volunteer that:
>
>1. All animals are connected.
>2. A single animal is not eaten (Godzilla)
>3. There's a loop in the diagram:  human eats chicken eats mosquito eats
>human eats chicken etc...
>
>These same facilities would be useful to sighted people when the diagram
>gets really big."

Fantastic!  This would be more useful than what I was thinking of at first.

">What's an "interesting" relation?  That's subject specific I'd think."
Yes, I think so too.  Since "interesting is probably subjective, this would most likely 
have to be determindd by, in the first instance but not limited to, the creator of the chart/diagram.  What do I as the creator of this diagram want my readers to get out of it? 

-Steve







------
Steven McCaffrey
Information Technology Services
NYSED
(518)-473-3453


>>> "Leonard R. Kasday" <kasday@acm.org> 08/19 3:59 PM >>>
Yes we definitely need interactivity.  And it needs to go beyond simple
walking around the tree.  As Steven emphasizes, it has to quickly answer
the questions a sighted user can quickly answer.

Here's an example, in which relations are shown in XML: a chart of animals
and plants with the relation "eat", e.g.

<eat consumer="anteater" meal="ant" />
<eat consumer="ant"      meal="sugar" />
<eat consumer="ant"      meal="wheaties" />

You can represent this in a diagram in which the anteater is connected by
an arrow to an ant which in turn is connected by arrows to sugar and
wheaties, as shown by the following ascii art (included to accommodate
sighted readers)

anteater--eat-->ant--eat-->sugar.
                 |
                 +---eat-->wheaties.

end of ascii art.

A sighted user looking at ant can immediately see that it's eaten by
anteaters and it eats sugar and wheaties.  In other words, what the XML
shows.  But there's more.

Imagine what happens if the diagram is a lot larger.  Assuming the diagram
is drawn clearly and isn't much too large, a sighted person can quickly
answer:

1. Is there a single animal at the top of the food chain?
2. Are there any animals that eat each other?
3. What animals eat lots of things?
4. Does the diagram have food loops where the last one comes around and 
    eats the first, e.g. human eats chicken eats mosquito eats human eats
chicken etc...

In principle, a determined blind user can figure this out by walking around
the tree, but there should be facilities to make it easier.  That's why in
addition to having an underlying abstract representation, we need tools to
conveniently answer questions such as the above.

For some people it would be appropriate to express the questions in
mathematical form, e.g. "are there are nodes x,y with arcs x to y and y to
x"?  For other users we would need subject specific questions: are there
any animals that eat each other?  The subject specific would be harder to
program.

Actually, it goes beyond this.  The user shouldn't even have to think of
the questions.  The program should identify "interesting" relations and
point them out to the user.  In other words the program would volunteer that:

1. All animals are connected.
2. A single animal is not eaten (Godzilla)
3. There's a loop in the diagram:  human eats chicken eats mosquito eats
human eats chicken etc...

These same facilities would be useful to sighted people when the diagram
gets really big.

What's an "interesting" relation?  That's subject specific I'd think.


Len



At 02:18 PM 8/19/99 -0400, Steven McCaffrey wrote:
>   
>Hi Dave, Karl, Len, Charles etal:
>
>"...(say) a hyperlinked HTML version
>for the VI members of the group,..."
>What is this version like?  If a blind person tabbed from link to link,
what would be spoken by a screen reader (i.e. what is the linked text?)
>A static HTML version  would be o.k. for input to a more interactive
program but not sufficient for output for blind 
>users to gain equivalent access to the underlying information structure.
A good exercise is to try to comprehend a chart/diagram you have not seen
before by having it described to you (i.e read aloud) by a
friend/colleague, without, of course, looking at it yourself.  The words
(labels of nodes) and relational information (e.g. (abstract tree data
structure terminology)"is a child of  or (more concretely) for an
organizational chart  "works for") goes past your ears.  Visual information
allows the viewer to refresh his/her memory simply by focusing her/his eyes
on any deisired portion of the picture.  To gain the same flexibility, you
would have to ask your friend/colleague, or computer, to read something of
interest, at the desired level of detail, again. Thus the need for
interactivity.
>  -Steve
>
>
>
>
>
>
>------
>Steven McCaffrey
>Information Technology Services
>NYSED
>(518)-473-3453
>
>
>>>> "Dave Pawson" <dave.pawson@virgin.net> 08/18 2:16 PM >>>
>> The Object Management Group <www.omg.org> has done a lot of work in this
area.
>In particular, I think their Meta-Object Facility (MOF) and XML Metadata
>Interchange (XMI) may be applicable.
>>
>> MOF is a Meta-Meta-Modelling Language: a syntax and semantics for
describing
>other meta-models: org charts, schematics, computer systems, whatever. XMI
is an
>XML format for exporting and importing arbitrary meta-models to and from MOF.
>Through XMI, any meta-modeling language could be converted into any other
>meta-modeling language.
>>
>> *In theory* any model could be converted into XMI for storage on a
server and
>transmission over the Web, e-mail, whatever. A User Agent can parse the
XMI to
>read the model and present it to the user. To present a different class or
set
>of models, you develop a meta-model, XML DTD, and XMI transforms. Optionally,
>you develop stylesheets for different presentation media.
>
>Now we are talking! <grin/>
>
>I knew there would be other uses for XMI.
>I had said if I could draw the flowchart, I can
>model it in XML.
>Why invent my own DTD when omg have done
>it for me.
>
>Love the idea.
>
>Love to see a simple implementation
>so that when my colleagues say
>can I have a copy, I use the XSL transforms
>to convert from the XMI to the graphical
>form for sighted colleagues,
>and to (say) a hyperlinked HTML version
>for the VI members of the group, just
>as I do with the rest of the presentation
>which is text based!
>
>Yippee.
>Love the ideas, now how to select from
>the crap set of graphical symbols in
>the UML guide graphical set <yuk/>
>to use them for
>QFD charts, QPD diagrams, system
>symbolic diagrams .........
>
>regards, and tks for a great idea, DaveP
>
>
>
>
>
>
-------
Leonard R. Kasday, Ph.D.
Universal Design Engineer, Institute on Disabilities/UAP, and
Adjunct Professor, Electrical Engineering
Temple University

Ritter Hall Annex, Room 423, Philadelphia, PA 19122
kasday@acm.org        
(215) 204-2247 (voice)
(800) 750-7428 (TTY)

Received on Friday, 20 August 1999 10:28:17 UTC