RE: Graph data anyone?

[TomBP]

>I think that this is a useful approach.  Consider that the purpose of the
>graph is visualization ***for a person***.

Exactly!

>People have different
>visualization needs for different types of rdf (and other, of course)
>graphs, and may even have a need for more than one vusialization style for
>the same data set.  It would be virtually impossible, I think, for a single
>processor to "understand" what style was needed and what parts of a given
>graph would contribute to it.

I don't think it's as bad as that! There are really two aspects here - the
structural and the visual representation. An awful lot of the visualisation
aspect is taken care of by SVG.  The way I've been approaching the
structural side so far is to have each graph represented within the app in
each required form, so adding a node (of any kind) would add a node to the
raw RDF model, the SVG model, the RGML model and whatever else. Each of
these models is backed by a common model, so they all have the same
interfaces. To interpret (and generate) data from an arbitrary RDF schema
should only mean putting a bridge in place between the source representation
and these models - the way I've got planned is through using a simple
dictionary, e.g.

CERIF.Publication -> Node
CERIF.Project-title -> Node

Defining the dictionary directly like this in RDF won't immediately offer
bidirectionality, but adding one or two details from the source
class/property will make it clear internally exactly what is being referred
to, enabling round-tripping (for editing). The *major* advantage here would
be that it will be possible to narrow down the data presented visually to
what is relevant, and not overload the user. Or the system - though my model
code can take in the 15,000+ statements in Sergei's data, it runs out of
memory while running the (visual) layout algorithm. One prospect is to use
nested/linked graphs, which could be really neat in SVG (the nesting is
actually quite high on my to-do list, it turns up quite a lot, e.g. in
Conceptual Graphs).

>This knowledge then needs to be stored somewhere, and better to be in a
>graph display definition file than hard-coded in.

Yep, that's pretty much how I've been thinking about it, given an arbitrary
RDF file there would be the following needed to represent it visually :

* source RDF
* source RDF Schema
* model-mapping RDF (RDF model <-> domain model)
* view CSS

taking these as inputs, the following would be some of the possible outputs
:

* 'plain' SVG
* graph model (RGML) RDF
* merged model-mapping & graph-model
* SVG with embedded RDF (any RDF from above)

(btw, the architecture that I'm using makes it relatively straightforward to
add other inputs & outputs - in fact the one I started with was a made-up
XML format for departmental organisation, only later did I add RDF)

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

>You know, this reminds me of XML Spy's ability to give you a editable
>display page for an xml file, based on a template built for each
>type of xml
>document.

Hmm - I've not seen that, XML Spy was rather pricey last time I looked,
maybe they've got an eval version...

Cheers,
Danny.

[1] http://derpi.tuwien.ac.at/~andrei/rdfdata/tuwien.daml

Received on Friday, 11 January 2002 10:42:15 UTC