Re: RDF in SVG (or other XML)

"Danny Ayers" <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.

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.

Received on Friday, 9 August 2002 12:20:37 UTC