Identifying Parts of SVG.

Jim Ley jim at j...
Mon Apr 29 17:47:14 UTC 2002


"Dan Brickley" <danbri at w...>
> On Sun, 28 Apr 2002, Jim Ley wrote:
>
> That page shows paths from some specified person, in this case William.
So
> he's in the first picture of every row. The 'old geezer' as he'd
probably
> put it. http://rdfweb.org/people/danbri/2002/02/blindless/ (his book,
> XHTML'd) and homepage for more info: http://w3.gorge.net/love26/
>
> I don't know that much about SVG internals. Most detail I've seen is
the
> http://www.w3.org/TR/SVG-access/ note at W3C. I would like to revisit
our
> discussion about conventions for representing SVG structures (paths at
> least) within the RDF graph, which I guess is almost the opposite of
what
> you're talking about here.

On the SVG internals it would probably be simply a case of identifying
them - so we say

(wn wordnet NS, img some new namespace or whereever we put these.)

http://jibbering.com/2002/4/example.svg#A img:isa wn:rectangle .

so we identify the part of SVG via xpointers (I don't like xpointer, but
it it's probably best.) and they say what it is via the img:isa (and any
other properties we may want.) The navigation information which we want
to add is currently only 4 values, for what the element in the
left/right/up/down direction is, so you might have:

http://jibbering.com/2002/4/example.svg#A nav:right
http://jibbering.com/2002/4/example.svg#B .

For an example see http://jibbering.com/2002/4/example.svg (the RDF is
embedded in a metadata element.)

The limitations of this approach is that you're limited to describing
elements which are well structured and in a heirachy in the SVG - you can
only point to elements with an ID, and only then the whole element. This
prevents you from pointing to parts that are spanned by multiple
elements, or content which is authored so as to not nicely group elements
under ID's.

So an alternative would be instead of basing the part on the svg elements
we base it on the visual rendering of the SVG - the advantage is
flexibility, we can use the same format for other image types, raster
aswell as SVG - the disadvantage is we lose the accessibility data
features of SVG itself (we don't know which elements the desc/title apply
to.) However if we're annotating 3rd party images with our own
descriptions this may not be too bad.

I already have examples of the above, in my codepiction path data
http://jibbering.com/svg/codepiction.html this looks like:

http://jibbering.com/2002/4/example.svg img:hasPart _:1 .
_:1 rdf:type img:Polygon .
_:1 img:polypath "M 0,0 L 10,10 L 0,20 z" .
_:1 foaf:regionDepicts _:2 .
_:2 rdf:type wn:Rectangle .

(where the polypath is the same as the SVG path syntax and is the
outline.)

> We seem to flip and flop between putting the
> RDF inside the SVG and vice-versa!

Well we've got two different things, sometimes we want to describe the
image and what's in it, and others we want to say we've got this, this
part of this image is it. They are inverses.
http://jibbering.com/rdfweb/example.rdf and
http://jibbering.com/rdfsvg/example.rdf show them I believe (in the first
I want to say something about the two shepherds, in the second I want to
describe what's in the image.

> If you've got examples to post, that'd be good. We could try making
> different representations of the same scenario...

Well that was all waffle, there's a sprinkling of examples though...

Jim.




More information about the foaf-dev mailing list