W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 1999

Re: How to describe Flowcharts, Schematics, etc

From: Leonard R. Kasday <kasday@acm.org>
Date: Fri, 13 Aug 1999 11:10:47 -0400
Message-Id: <3.0.32.19990813111046.011cab5c@pop3.concentric.net>
To: Charles McCathieNevile <charles@w3.org>
Cc: w3c-wai-ig@w3.org
Re Charle's remark that 

> maybe we should look at hot to describe the relationships between
>elements of a diagram, and go from tehre to representing the elements and
>relationships in SVG...

Here's a couple of thoughts on what we want to represent and the details of
exactly how we would represent it.  

First, what we want to represent.  Lets take Steve's example of the
questions a person might want answered by the diagram:

>To
>  take a very simple example, if I have an organization chart, I might ask
>  "Who is the director of the organization?"  or "Who is the head of my
>  department/division?" or "Who is my counterpart in office x?"etc. 

These are questions that deal with relations between object in the diagram.
This suggests that we anticipate all these questions and specify answers.
The author could put in all the answers by hand.  Or there could be logic
tools that do it mostly automatically, using logic programming. For
example, the author could specify rules that define "counterpart" a program
could figure out all counterparts.

As for how we represent it. Rather than make it part of the new scalable
vector graphics (SVG) standard I'd suggest that we use RDF to specify the
relationships between objects in the SVG graphics.  The logic programming
could the be done by e.g.
the logic-based rdf interpreter at
http://www.aifb.uni-karlsruhe.de/~sde/rdf/ .

Yet another way, which goes even further in separating content from
structure, would be to represent the abstract information (e.g.
organization chart) as XML and use a  style sheet to translate that to
graphics.  Then the RDF, and the logic programming, could apply directly to
the abstract information.

These would all make the diagrams more useful to everyone (and to machines)
since they wouldn't just be pictures anymore: they would be information.

Len
-------
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, 13 August 1999 11:08:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:33 UTC