W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2002

RE: Graph data anyone?

From: Danny Ayers <danny666@virgilio.it>
Date: Fri, 11 Jan 2002 12:18:33 +0100
To: "Andrei S. Lopatenko" <andrei@derpi.tuwien.ac.at>
Cc: <www-rdf-interest@w3.org>
Message-ID: <EBEPLGMHCDOJJJPCFHEFIEPIEKAA.danny666@virgilio.it>
Hi Andrei,

>I have a look at your pages about visualization of RDF and I found
>that your
>software looks excellent

Most kind. Before going any further I should point out that the RDF
visualisation was really just something on the side (at least at this
point). What I'm aiming for is a generic graph visualisation/editing
toolkit, which could be used anywhere graphs are found - e.g. organisational
charts, web site maps,  'mindmaps', geneology charts, appointment planning,
neural nets... The fact that I'm using RDF-XML as the serialisation format
(it'll be RGML with domain-specific stuff added) made the RDF visualisation
an early subgoal.
BTW, RDF chosen for interoperability, SVG for interop/accessibility, Java
for platform independence (client or server-side) - Jena & Batik being
available makes the whole idea a lot more do-able.

>I just have a few notices. I tried to use different RDF visualization
>software (primarily that RDFViz) in last half year and have some comments
>RDF Schema of data as usual not intended for visualization of data. The
>primary objectives of RDF (DAML) Schema  development is
>    to provide best semantic description of data,
>For such aims as  to represent data so it would be easily to implement
>information retrieval operations on them, perform reasoning, exctract
>knowledge, but not vizualize
>Good vizualization of result is not usually a key  factor considered in
>development of most schemas. So when you try to vizualize data you get
>something correct, but not easy to understand and use.
>It would be very good if  some instructions to  vizualizer could
>be provided
>to make vizualized graph more usable

I agree entirely. Though if you could edit the diagrams then it becomes a
whole new ball game.

>The simplest, but are very important features (at least for my cases) for
>RDF vizualization
>1 instances of some classes must be ommited from the graph
>2 the some properties must be ommited from the graph
>3 values of some properties must be used to label nodes and edges
>4 some paths must be replaced by one edge
>But all rules can not be described.
>It would very good to have some canonical DAML schema intended only for
>vizualization which defines such terms as node, edge, their attributes
>(length, color of borders, filling-in color, label, position).
>Then application, knowing about requirement to vizualize data,  can
>transform real RDF data into RDF data for vizualization. It'll solve a lot
>of my problems

Thanks for these pointers. This is really the big task ahead of me (though
the editing aspect will take some time!) - somehow making the drawn graph
more closely represent the intended semantics in the domain, rather than the
RDF/DAML representation. This would be relatively straightforward to
hard-code for a specific domain, but making it generic seems a lot harder.
At present I'm thinking about providing an additional (RDF) data file,
containing a mapping between the visual graph representation (which will
correspond to the 'humanised' semantics) and the underlying data in the RDF
(or DAML) model. One-way filtering (like XSLT) would again be more
straightforward, but keeping the models in sync (for editing) makes things
more difficult. Following your suggestions here it would seem that such a
transform tool might be useful outside of the visual app, that's given me
something to think about ;-)

At the moment these two goals (editing & domain 'relevance') are my main
targets, though further down the line I'd like to add a little reasoning
based around the underlying graph model(s) - for instance, there are quite a
few domains in which shortest-path or travelling salesman algorithms could
be useful.
Received on Friday, 11 January 2002 06:34:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:34 UTC