- 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>
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