W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > March 2003

Re: reminder: RDF Core specs in Last Call

From: Dan Brickley <danbri@w3.org>
Date: Fri, 28 Mar 2003 09:52:20 -0500
To: w3c-rdfcore-wg@w3.org, www-rdf-comments@w3.org
Message-ID: <20030328145220.GG29710@tux.w3.org>
Fwd for tracking; comments from Chris Lilley re SVG & RDF.

Brian, he asked for an extension... should these comments go into 
LC processing?

attached mail follows:


[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 Friday, 28 March 2003 09:52:21 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:56:15 EDT