RE: TRANSFORM SVG2RDF

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

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

fwiw, here's a sample of the kind of thing I've been producing using Jena +
Batik to represent graph structures (it isn't an RDF graph, but a graph
described in RDF):

 (SVG is the default namespace)

    <g id="edges">
        <g id="e1">
            <line y2="155" marker-end="url(#triangle)" x1="113" x2="116"
y1="97"/>
            <text class="" transform="translate(115,123)">
                strikes
            </text>
        </g>
...

   <g id="vertices">
        <g id="v1" transform="translate(246,28)">
            <rect x="-50" width="100" y="-15" height="30" class="vertex"/>
            <text>
                hook
            </text>
        </g>
...

The point about which arcs are connecting which nodes could perhaps be got
around with a single metadata element in the edges maybe <xxx:edge
xxx:source="v1" xxx:target="v2"/>. Or neater perhaps using XML nesting/SVG
grouping (SVG should maintain order, so I guess you could say the first
contained element is the source and the second the target).

However, I spent quite a few fruitless hours trying to get some nice inline
metadata in the SVG, but after a bit gave up and had the RDF at the end of
the same document (in a <metadata> element), which was looking something
like this :

            <idea:Edge rdf:about="#e1">
                <RDFNsId1:source rdf:resource="#v1"/>
                <RDFNsId1:target rdf:resource="#v2"/>
            </idea:Edge>

            <idea:Vertex rdf:about="v1" rdfs:label="hook"

rdf:type="http://www.w3.org/2001/04/infoset#Element"/>

(local names were used here with the IDs unique within the doc, and, errm,
the Element type shouldn't have been there ;-)


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

The modelling should certainly be a lot more solid & versatile, but it could
get a bit heavy for applets - I must have another look at yoour source ;-)

Cheers,
Danny.

Received on Friday, 11 October 2002 07:12:22 UTC