You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Danny Ayers <da...@virgilio.it> on 2002/08/09 12:43:23 UTC
RDF in SVG (or other XML)
The SVG spec uses RDF in its examples of what to put in <metadata> elements,
and I was wondering how people were getting on with this in practice. In
particular, unmarshalling the markup in such a way that references between
the SVG elements and RDF statements are maintained/created in their
respective models strikes me as potentially tricky.
It's a fairly general problem - I know folks have done RDF scraping from
(X)HTML, but I can't remember seeing anything that kept references to
fragments annotated with the RDF.
The simplest way that occurs to me would be to run the source doc through
stylesheets first to split it into separate SVG and RDF DOMs, and then pass
these to appropriate APIs. If the original generator included
cross-references in the RDF then the XSLT should be pretty trivial. This
does seem like a bit of a sledgehammer approach though, presumably it should
be possible to do it more elegantly using DOM programmatically.
This is the kind of thing that only needs implementing once, and I am of
course hoping someone (who is liberal with their code!) has already done
this using Batik + Jena or similar ;-)
Cheers,
Danny.
---
Danny Ayers
<stuff> http://www.isacat.net </stuff>
Idea maps for the Semantic Web
http://ideagraph.net
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: RDF in SVG (or other XML)
Posted by Jim Ley <ji...@jibbering.com>.
"Danny Ayers" <da...@virgilio.it>
> Thanks Jim - I thought cc'ing you might get a result ;-) I'll have a
nosey
> around the tools & examples you suggested.
Yes, I am also subscribed to all the lists you posted to aswell...
> I do have a feeling though
> that the mixin approach might be better for a whole host of
applications.
It probably is, and I don't think there are too many problems with it,
ARP finds it okay, from withinSVG I can get it easily enough, I'm sure
raptor not finding the element is simple to fix, as it does in xhtml.
> 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 disagree that the SVG metadata element says that, all the examples I've
seen still require all the rdf bits I had in - the metadata element
doesn't have to contain RDF.
> 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.
The img: stuff is actually there becuase of what I consider a significant
flaw in SVG (you can't embed a raster image at its original size unless
you know the height and width - so yes it all should be unnecessary - I
just need to say it to make using it in SVG possible.) As you say the
regionDepicts is inherent in the grouping - so you could give the g
element an ID, and use that as the region rather than my img:Polygon.
> In other words :
> <svg xmlns={svg,xlink,foaf}...>
> <svg:g>
> <svg:metadata>
> <foaf:name>Rocky the RockWabbit</foaf:name>
> </svg:metadata>
> <svg:image xlink:href="photo.jpg">
> <svg:polygon visibility="hidden" points="..." />
> </svg:g>
> </svg>
>
> 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).
limiting the SVG metadata element to RDF isn't sustainable IMO, and we'd
have parsing problems as you not, if we include a full RDF document, at
least we get to use the same parser and vocabulary if it is embedded or
not, for the sake of a little visual bloat, but then XML serialisations
are always about visual bloat IME.
> The reason I'm coming from this angle is because my application is
crying
> out for a serialization syntax like SVG with embedded RDF.
So go for it :-)
> 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.
Ah, I don't know how other RDF parser's would go for it, but my SVG
capable one would have no problems with multiple rdf documents in all the
metadata elements, but it would be a pretty bloated document - you could
use a non-RDF metadata scheme and provide an XSLT to convert it into RDF
by combining your simplified svg/metadata to RDF.
> *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...
If you go the 2 file approach, you get the 1 file approach for free, just
stick the whole seperate rdf file in a metadata element at the end.
Jim.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: RDF in SVG (or other XML)
Posted by Danny Ayers <da...@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}...>
<svg:g>
<svg:metadata>
<foaf:name>Rocky the RockWabbit</foaf:name>
</svg:metadata>
<svg:image xlink:href="photo.jpg">
<svg:polygon visibility="hidden" points="..." />
</svg:g>
</svg>
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...
Cheers,
Danny.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: RDF in SVG (or other XML)
Posted by Jim Ley <ji...@jibbering.com>.
"Danny Ayers" <da...@virgilio.it>
> The SVG spec uses RDF in its examples of what to put in <metadata>
elements,
> and I was wondering how people were getting on with this in practice.
In
> particular, unmarshalling the markup in such a way that references
between
> the SVG elements and RDF statements are maintained/created in their
> respective models strikes me as potentially tricky.
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. 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.
So all my RDF I store seperately, and just say the RDF refers to a
seperate file, using path data for what I'm talking about - this is not
robust against user stylesheets in the SVG display, and can cause
problems with changes - however it does mean I can easily annotate raster
images, or even movies etc. with the same vocabulary.
> It's a fairly general problem - I know folks have done RDF scraping
from
> (X)HTML, but I can't remember seeing anything that kept references to
> fragments annotated with the RDF.
Putting (also at http://jibbering.com/2002/8/rocky.svg ):
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<title>Rocky!</title>
<desc>Rocky the Rock Hyrax</desc>
<a xlink:href="mailto:rocky-fanmail@rdfweb.org"><image id="rock_hyrax"
clip-path="url(#ref0)" opacity="1" width="640" height="480" x="0" y="0"
xlink:href="http://swordfish.rdfweb.org/photos/2002/06/27/002281.JPG">
</image></a> <g clip-rule="evenodd" > <clipPath id="ref0"> <path
id="pathref0" d="M405 151 L405 151L356 146 L343 167 L338 181 L300 180
L256 191 L185 240 L181 246 L163 301 L193 327 L193 343 L194 347 L231 352
L265 327 L309 310 L330 317 L335 300 L383 232 L393 205 L393 186 L405 178
L410 168 z L405 151 z" fill="red" /></clipPath></g>
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="#rock_hyrax">
<foaf:name>Rocky</foaf:name>
</rdf:Description>
</rdf:RDF>
</metadata>
</svg>
through the RDF validator, correctly sorts out the references, (my cygwin
raptor rdfdump doesn't seem to find anything with --scan) So I don't
have any problems doing it, I just find the rdf view in
http://jibbering.com/rdfsvg/1025711279152.rdf more useful a view rather
than embedding.)
> The simplest way that occurs to me would be to run the source doc
through
> stylesheets first to split it into separate SVG and RDF DOMs, and then
pass
> these to appropriate APIs. If the original generator included
> cross-references in the RDF then the XSLT should be pretty trivial.
This
> does seem like a bit of a sledgehammer approach though, presumably it
should
> be possible to do it more elegantly using DOM programmatically.
Well, raptor (should) and arp both can get at the RDF bits without
trouble.
Inside an SVG document (probably only in ASV), my RDF parser can also
access the RDF:
http://jibbering.com/2002/8/rocky-parser.svg , but I still prefer the
seperate view as being neater - but I've not found any problems doing it.
Jim.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org