Re: How to describe Flowcharts, Schematics, etc

    
Hi Len, Charles etal:
I'm afraid I am not up to speed on any of XML,RDF or SVG so I can't add to any of the implementation discussion.  At this  point I would like to say that I agree with the notion of choosing a representation that separates structure from content as Len said:   
">
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."

Yes, excellent.  I'll try to read up on XML and RDF.  Any suggestions for people new to these formats/languages
-Thanks,
Steve

?


  




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


>>> "Leonard R. Kasday" <kasday@acm.org> 08/13 11:08 AM >>>
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 13:57:08 UTC