RDF in SVG [was Re: reminder: RDF Core specs in Last Call]

Reading through this, the comment I see is a request that the syntax doc 
contain add a section 10 to discuss embedding RDF in SVG.  I note that SVG 
has created a very nice slot for inserting RDF (and any other) metadata 
into SVG :)  I also note an offer from Chris to help draft such a section.

This looks to me as a nice to have, but not essential, and given the 
comment is very late, I don't think we have an obligation to accept it.

However, if the syntax editor, (or possibly the primer editor) were 
willing, we might indicate to Chris that if he were to provide us with a 
draft, we would try to fit include it.  Another possible home would be the FAQ.

I'm open to advice from our team contact or elsewhere, but I suggest:

   o we don't accept this as a last call comment - too late and not substantive
   o we invite Chris to prepare a draft on how to embed RDF in SVG
   o the syntax editor or primer editor have discretion to use the material
   o if it doesn't go in a rec track doc we'll put it in the FAQ, or 
possibly Chris could put it in the SVG FAQ and we could link to it - ah - 
google doesn't find a W3C FAQ for SVG

Comments?

Brian

At 09:52 28/03/2003 -0500, Dan Brickley wrote:
>Fwd for tracking; comments from Chris Lilley re SVG & RDF.
>
>Brian, he asked for an extension... should these comments go into
>LC processing?
>
>Return-Path: <chris@w3.org>
>Received: from localhost (IDENT:root@localhost [127.0.0.1])
>         by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2SC2RrB001121;
>         Fri, 28 Mar 2003 07:02:28 -0500
>Date: Fri, 28 Mar 2003 13:02:22 +0100
>From: Chris Lilley <chris@w3.org>
>X-Mailer: The Bat! (v1.62i) Personal
>Reply-To: Chris Lilley <chris@w3.org>
>Organization: W3C
>X-Priority: 3 (Normal)
>Message-ID: <10277683046.20030328130222@w3.org>
>To: www-svg@w3.org, Dan Brickley <danbri@w3.org>
>Subject: Re: reminder: RDF Core specs in Last Call
>In-Reply-To: <20030207141202.GR14748@tux.w3.org>
>References: <20030207141202.GR14748@tux.w3.org>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>X-Spam-Status: No, hits=-2.8 required=5.0
>         tests=EMAIL_ATTRIBUTION,HTML_EMBEDS,IN_REP_TO,JAVASCRIPT,
>               NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,
>               SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_THEBAT
>         version=2.43
>X-Spam-Level:
>X-FOAF-Whitelist: YES
>X-FOAF-SharedWhitelist: NO (chris@w3.org unmatched in RDF: 
>/tux/u/danbri/s-rubyrdf/util/foafwhite/data/whitelist)
>
>[Note - this mail was written on 18 Feb 2003. It is being sent out to
>clear an action item]
>
>On Friday, February 7, 2003, 3:12:02 PM, Dan wrote:
>
>
>DB> Per http://www.w3.org/Graphics/SVG/Group/SVGcharter2.html#comms
>DB> I understand this to be an appropriate list for getting the SVG WG's
>DB> attention. Please pass this on to the WG member list if deemed
>DB> appropriate.
>
>This is an initial and personal response. It does not, necessarily,
>represent the consensus of the SVG WG; such response will be
>forthcoming once it has been discussed there. However, where i am
>reporting on what SVG 1.0 and 1.1 do, assume that this is indeed what
>the WG believes.
>
>DB> SVG WG,
>
>DB> This is just a quick note to remind SVG folks that the
>DB> RDF Core specs are in Last Call (for details see Brian McBride's
>DB> message to the chairs list, copied into public RDF IG space at
>DB> http://lists.w3.org/Archives/Public/www-rdf-interest/2003Jan/0161.html).
>
>Thanks.
>
>DB> We would be particularly interested in feedback from the SVG WG on
>DB> the RDF syntax specification, and in particular draw attention to
>DB> section 9 where we touch on the issue of embedding RDF within _HTML_
>DB> documents (http://www.w3.org/TR/rdf-syntax-grammar/#section-rdf-in-HTML).
>
>I agree that embedding RDF in HTML is a complex mess. In retrospect,
>the fact that RDF encouraged people to make invalid HTML documents was
>not the best idea, especially since HTML browsers do not use parsers
>as such. The analysis by Sean B. Palmer is a good one
>
>http://infomesh.net/2002/rdfinhtml/
>
>DB> We don't currently discuss embedding of RDF within SVG explicitly
>DB> in the RDF Core specs,
>
>So I see. A pity; I request (as an individual commentor) that you do
>explicitly discuss embedding of RDF within SVG in your document. A new
>section 10 "Using RDF/XML with SVG" would seem appropriate. I would be
>happy to help draft such a section.
>
>DB> but similar issues arise.
>
>I disagree strongly with that. What 'similar issues' do you imagine
>might apply to SVG?  In discussions with Eric Miller he seemed to
>think that we had none of these issues.
>
>Lets look at the opening paragraph of Sean's document:
>
> > Since there is no one standardized approach for associating RDF
> > compatible metadata with HTML, and since this is one of the most
> > frequently asked questions on the RDF mailing lists, this document
> > is provided as an outline of some RDF-in-HTML approaches that the
> > author is aware of.
>
>Lets contrast that with the case for SVG:
>
>There is one standardized approach for associating RDF
>compatible metadata with SVG - the metadata element, introduced
>explicitly for that purpose. See
>http://www.w3.org/TR/SVG/metadata.html
>Since this is such a non-issue it has rarely been the subject of
>debate. Since there is only one approach, a comparison of possible
>approaches and workarounds is somewhat moot.
>
>To continue a compare and contrast of Sean's document with a
>fictitious analogous RDF in SVG document:
>
> > Ever since RDF's inception, people have been wanting to embed it in
> > their HTML documents. In fact, ever since HTML was invented, people
> > have been wanting to embed some sort of metadata for extraction and
> > processing by user agents and crawlers.
>
>Ever since SVG's inception, people have been embeding RDF in their SVG
>documents. In fact, ever since SVG was invented, people have been
>embeding some sort of metadata for extraction and processing by user
>agents and crawlers.
>
> > However, after many raging discussions within the W3C's RDF Interest
> > Group and elsewhere, there is still no one standard method for
> > associating RDF with HTML. This is an important thing for the
> > Semantic Web community to resolve: even the author has quite
> > recently found himself wanting to associate RDF with HTML for
> > certain applications, but has had to put-aside the application due
> > to the lack of a standard approach.
>
>The one standard method for associating RDF with SVG is an important
>thing for the Semantic Web community to utilise.
>
> > Embed XML RDF Part I: Eschew Validation
>
> > In the "validator.w3.org be damned" approach, one would generally
> > use the abbreviated XML RDF syntax so as to hide the contents from
> > older browsers (which usually render the contents of any element,
> > but not attribute values).
>
>In the "DTDs suck" approach, one would generally accept that mixed
>namespaces and DTDs mix like oil and vinegar - with much shaking and
>only briefly - while noting with relief that the abbreviated XML RDF
>syntax is not needed as there is no need to hide the contents from
>older browsers. All SVG implementations use XML parsing. In addition,
>unlike HTML (which specified that browsers should render the contents
>of any element, but not attribute values), SVG specifies that content
>in a non-SVG namespace that is not in a foreignObject element has no
>effect on rendering:
>
>http://www.w3.org/TR/SVG11/extend.html#PrivateData
>23.1 Foreign namespaces and private data
>
>"SVG allows inclusion of elements from foreign namespaces anywhere with
>the SVG content. In general, the SVG user agent will include the
>unknown elements in the DOM but will otherwise ignore unknown
>elements. (The notable exception is described under Embedding Foreign
>Object Types.)"
>
>As an example, see
>http://www.w3.org/TR/SVG/metadata.html#Example
>
>It is possible to extract an SVG Document Fragment from such a mixed
>namespace document and see if it is conforming:
>http://www.w3.org/TR/SVG/conform.html#ConformingSVGDocuments
>
> > Embed XML RDF Part II: Embrace Validation
>
> > This "create a new XHTML family" approach basically involves hacking
> > up a small DTD (document type definition) using XHTML Modularization
> > for a variant of XHTML, putting it on the Web, and then referencing
> > it from your document. The main drawback is that the DTDs are large
> > and relatively complex; this is not a viable approach for typical
> > HTML authors.
>
>
>This "SVG 1.2" approach basically involves referencing the standard
>SVG 1.2 Schema from your document. This declares (will declare) the
>content model of the svg metadata element to be 'any well formed xml'
>and thus allows validation of the mixed namespace SVG document without
>constraining the elements and attributes used in the RDF in any way
>whatsoever and without requiring the document author to go hacking up
>anything.
>
>Note that the actual content is exactly the same in this case as for
>Embed XML RDF Part I: Eschew Validation; except that there is perhaps
>an inline reference to a schema location.
>
> > Utilize the Object or Script Elements
>
> > HTML has two elements for including non-HTML media; <object>, and
> > <script>. <object> is a generic element for including any external
> > object, whereas <script> is available for embedding executable
> > scripts.
>
>SVG has two elements for including non-SVG media; foreignObject and
>script. Neither are suitable for putting metadata in. Don't do that.
>Put it in a metadata element instead. The Semantic Web needs
>consistent usage.
>
> > <link> to the Metadata
>
> > Arguably the purest solution from an architectural point of view,
> > making use of the <link> element has been the object of criticism
> > since maintaining the metadata externally to the RDF is seen as an
> > inconvenience. Proponents of the solution contend that CSS,
> > JavaScript, and images are already maintained externally without
> > fuss, and that retrieving external files does not take much more
> > programming than extraction (in fact, possibly less so).
>
>Arguably the purest solution from an architectural point of view,
>pointing to external metadata has been the object of criticism
>since maintaining the metadata externally to the RDF is seen as an
>inconvenience. Proponents of the solution contend that CSS,
>JavaScript, and images are already maintained externally without fuss,
>and that retrieving external files does not take much more programming
>than extraction (in fact, possibly less so).
>
>There are three possible ways that it could be done; two are
>extensions to SVG and the third is already possible.
>
>a) Add an xlink:href on the metadata element
>b) Add another extmetadata element that is empty and has an xlink:href
>c) Point to the external metadata from the internal metadata, using
>RDF. This allows the arc between the SVG file and the external
>metadata to be labelled in a normal RDF style rather than inventing a
>parallel mechanism.
>
>DB> The SVG 1.1 spec
>DB> currently cites the older RDF syntax specification
>DB> (http://www.w3.org/TR/SVG11/metadata.html).
>
>Sure, we can update to your newer syntax specification. But all this
>stuff about hiding RDF from dumb HTML parsers is totally unnecessary
>for SVG.
>
>DB> Since SVG cites RDF in this
>DB> way, it would be particularly good to have some review from members of
>DB> the SVG WG.
>
>DB> Our Last Call period ends on 21st February 2003.
>
>Oops. Your email arrived while I was travelling and was not noticed
>due to backlog. Could we have a one week extension to 28 February for
>our official comments, please.
>
>DB> Any feedback or
>DB> review comments that the SVG WG provide would be greatly appreciated.
>
>DB> cheers,
>
>DB> Dan
>
>DB> (for RDFCore WG)
>
>
>
>--
>  Chris                            mailto:chris@w3.org

Received on Wednesday, 2 April 2003 11:38:02 UTC