W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 2002


From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Wed, 13 Nov 2002 17:22:07 +0000
To: Paul Prescod <paul@prescod.net>
cc: www-rdf-comments@w3.org
Message-ID: <13138.1037208127@hoth.ilrt.bris.ac.uk>

>>>Paul Prescod said:
> Dave Beckett wrote:
> > ...
> > What?  I've just noticed rdf:ID inside the XHTML bit.  That's not
> > going to be noticed by an RDF parser.  It only deals with
> > <rdf:RDF> <rdf:RDF/> blocks.  
> That should not be.

rdf:RDF is the beginning of the RDF/XML grammar; the document element
usually (but see below).  There is no way the syntax should have
opinions on content outside that.

> > We haven't spent a lot of time considering mixing these things like
> > this.  Sounds more like a web architecture issue.  For the TAG.  Ha ha.
> When you embed XHTML in SVG, you don't wrap the whole fragment in an 
> <html> element. I could list a variety of common embeddings and you'll 
> see that you seldom include the root element. (Schema in WSDL is an 
> exception, and does it as RDF does, but HTML in WSDL does not.

In SVG you use <metadata> element for embedding RDF - see the example
in the specification - and then inside that you use <rdf:RDF> if that
is the metadata format you want.  An RDF/XML parser does not deal
with anything outside the latter.  If SVG had chosen to require
RDF/XML as the only metadata format inside <metadata>, there would
be no ambiguity and you could do something else - see below(*) for more.

> The RDF specification should say specifically what an RDF processor is 
> looking for in a non-RDF document. I would propose that an 
> rdf:Description should be a proper root for an RDF fragment. ...

[You mean RDF/XML throughout here]

I really don't think an RDF/XML specification (or any other) should
say anything about other formats work, that is for them to define.  
They could have a wrapper element that says
    ... big chunk of RDF/XML ...
or something, that is not for RDF/XML to interpret.

However, the RDF/XML syntax specification does specify how to process
RDF/XML inside another XML format for when it is intended to be
processed as embedded RDF/XML.  You can find it at:

  7.2.1 Grammar start

It is all a question of context that is defined outside this
specification, external knowledge that the content it is rdf/xml (*)
- the containing format or protocol tells you this or some
other method.  If this is the case, you can omit rdf:RDF and the
embedding format can start the RDF/XML parser at the right
production.  The above link describes above how if rdf:RDF is
omitted, you can use any of the nodeElementList terms, in that case
rdf:Description would be one option.

If a standalone XML document has a root element that is not rdf:RDF,
the document is not something that this format deals with.

We are not changing the root element.

> ... Similarly, 
> a fragment rooted in rdf:About or rdf:ID should be interpreted as an 
> abbreviated rdf:Description.

Sorry, I don't understand this, can you give an example?

> I don't think it needs to be handled by the TAG. Other "how do I embed 
> X" issues are figured out just by the people defining the languages.

How you embed RDF/XML in other XML formats is something we have
addressed as above, but not how to mix and match XML formats.  That
is more of a general XML or web issue.  

This is what was happening in the example you were refering to but
removed - an rdf:ID attribute outside the rdf:RDF block but appearing
on an XHTML element.  If it was an html or XML ID that would make a
bit more sense but I'm unsure how it could be refered to.

RDF/XML is not an annotating XML format that you scatter around other
XML formats and then triples are infered.  It is an XML format with a
application/rdf+xml mime type and required(caveats above)
root element rdf:RDF.

Received on Wednesday, 13 November 2002 12:23:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:19 UTC