- 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>
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.
Received on Friday, 9 August 2002 12:00:52 UTC