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

RE: RDF in SVG (or other XML)

From: Danny Ayers <danny666@virgilio.it>
Date: Fri, 9 Aug 2002 17:51:45 +0200
To: "Jim Ley" <jim@jibbering.com>, "batik-users" <batik-users@xml.apache.org>, "Svg-Developers" <svg-developers@yahoogroups.com>, "RDF-Interest" <www-rdf-interest@w3.org>
Message-ID: <EBEPLGMHCDOJJJPCFHEFKEKJHGAA.danny666@virgilio.it>

Thanks Jim - I thought cc'ing you might get a result ;-) I'll have a nosey
around the tools & examples you suggested.

>I agree, I've kept them seperate so I have an RDF view of the data which
>is converted to SVG purely for output purposes.

This approach certainly makes sense from an annotation point of view. But
the issue of where the data should be located is somewhat bipolar - the
implication in the SVG spec is that the metadata describing the document or
elements within it will usually appear within the same document. Ok, this is
fine from the SVG point of view we've got a visual representation and some
additional information relating to it. The assumption in the spec is that
the author of the metadata *will* own the SVG. But this gets a bit ugly from
the RDF point of view, where the SVG representation might just be one of
many - the obvious answer is the separation of SVG & RDF as you describe
(and Seth Russell mentioned elsewhere), which incidentally also follows the
principle of separating data from presentation. I do have a feeling though
that the mixin approach might be better for a whole host of applications.

 I'm annotating image and
>I prefer doing it this way where the references don't point to elements
>in the SVG document, because this isn't robust against changes of the
>document, and also requires that you "own" the SVG document, limiting
>what you can annotate.

Yes, but the use of foaf:regionDepicts and your img: vocab is stepping way
outside of what is provided by SVG, where the use of <metadata> can make the
association - this is enough in itself. I wouldn't for a moment say there's
anything wrong with this approach, but it does seem to violate 'keep it
simple' a little - regionDepicts is implicit in SVG element grouping, and
the echoing of the SVG terms in img: seems redundant. In other words :

<svg xmlns={svg,xlink,foaf}...>
        <foaf:name>Rocky the RockWabbit</foaf:name>
    <svg:image xlink:href="photo.jpg">
     <svg:polygon visibility="hidden" points="..." />

Ok, so code to extract the metadata may need to be fairly complex, but it's
a functional black box that is conceptually simple (and could be pressed
into use with any other XML syntax).

The reason I'm coming from this angle is because my application is crying
out for a serialization syntax like SVG with embedded RDF. The main user
interface is graphical, but behind the scenes the displayed objects have a
lot of metadata attached - as well as per-document info, there's visual item
by item info. So it seems appropriate to keep the item info together, and
the obvious place is in the same fragment of the same document.

There's a whole bunch of applications that have a similar model, e.g.
architectural diagrams, where you might have a prefab shed as a visual
object, with associated non-visual data like roof="tin". Encapsulating the
representational information with descriptive information together in the
same object would strike me as being the 'natural' approach. I would suggest
that it would probably be more robust, as it doesn't require the maintenance
of explicit rdfNode <-> svgNode links. Scaled up or distributed, it might
also become disproportionately expensive to manipulate the documents once
the description of the objects gets physically fragmented. Ok, so the
Semantic Web is designed with this ability in mind, but surely it's easier
to point to one URI rather than a URI that contains a ref to another.

It's also worth noting that it would probably be easier for agents to
gracefully degenerate (that's not the word I was looking for, but it'll
do...) - if they can't show the picture then they may be able to show the
info & vice versa, without needing to get data from elsewhere.

*However* after mulling over the alternatives I'm looking at using the 2
file approach for the time being, though the embedded method has gone right
to half way down my to-do list...

Received on Friday, 9 August 2002 12:00:52 UTC

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