I tend to agree with Danny on the side of adopting an MVC approach.

First, I am not sure that the SVG -> RDF is possible in the first place, 
at least not without considering some processing to find out which nodes 
are linked by which arcs  (I don't think pure SVG will tell you that 
explicitely, it willl just give you the geometric (lower-level) 
information - unless the SVG uses groups and that kind of stuff, but I'm 
not sure that is even sufficient). If I am right, XSLT will probably not 
be able to handle the full transformation process. But I might be wrong 
on this, or you could be using a specific "trick" (XML ID/IDREF(S) 
mechanism, comments?) to represent this information in the SVG.

Why not adopt an approach similar to IsaViz [1] ? The environment is 
RDF-aware ; the graph is represented in a purely abstract (close to 
RDF/Jena model) way. This representation can be manipulated and 
imported/exported from/to RDF or NTriples, but also exported as SVG 
graphics. And it can be modified directly from the graphical view.



Danny Ayers wrote

>>Recently I joined to this list and I started to read something about
>>that I shouldn't use XSLT to generate RDF, but I can't see the  reason (my
>>poor brain ;) so How I should focus my project?, is It posible from a SVG
>>file to generate an RDF? , am I really lost?, I really would
>>appreciate any
>>sugestions or ideas.
>I think the SVG -> RDF via XSLT is doable in principle, but don't forget
>you'll need an XSLT engine so that might mean added weight. It's a matter of
>programming taste, but I don't see why the data model shouldn't be specified
>in RDF and exposed declaratively to SVG or Java graphics using XSLT. (btw,
>one of the precursors of what I'm working on was RDF2SVG [4], though the
>processing was done programmatically rather than using XSLT). If you do
>decide to go the XSLT route, you may find the XSLT RDF -> triples parser at
>[5] interesting.
>On one level, the approach you're talking about is rather back to front, as
>SVG is primarily a graphic language and you're talking of saving the graphic
>as RDF. If I were you I'd stand back from this and try and look at it from a
>Model-View-Controller angle. The view could be made of Swing objects, or it
>could be done using SVG. Re. the model - you want RDF, but is this the best
>way of modelling or maybe a simpler, generic node & arc graph model might be
>better, with RDF being another 'view' (i.e. import/export). Do you even need
>a graph model? I'm guessing yes from your description, but it may be that a
>(possibly xlink decorated) DOM tree might cover your requirements.
>Re. controller, well the implementation will depend on the model and view,
>but a critical point would be whether to use Java or something like SVG
>(with its own scripting). Personally I'm using Java, but then I've got the
>relative luxury of not worrying too much about app size.
>Don't forget that you've also got the possibility of doing some of the work
>Some other bits of kit that might be useful are Jim Ley's SVG RDF editor [1]
>(this would probably be the neatest lightweight solution) and Touchgraph [2]
>has a 'LinkBrowser' applet that sounds related to what you have in mind,
>though without the RDF (this would probably be the easiest solution). I may
>be wrong, but I think Alex Shapiro originally based his TouchGraph code on
>the example at [3]. (Incidentally, Murray Altheim is doing some work with
>TouchGraph + Topic Maps, though last time I looked he hadn't released
>anything). Alternately you could build the whole lot from scratch (this
>should be the most elegant solution ;-)
>I'm very interested in hearing about how you get on.
>Danny Ayers
><stuff> </stuff>
>Idea maps for the Semantic Web

Received on Thursday, 10 October 2002 03:21:42 UTC