W3C home > Mailing lists > Public > public-grddl-wg@w3.org > January 2008

RE: GRDDL and powder

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Thu, 24 Jan 2008 21:37:22 +0000
To: Jeremy Carroll <jjc@hpl.hp.com>
CC: "public-grddl-wg@w3.org" <public-grddl-wg@w3.org>, Phil Archer <parcher@icra.org>
Message-ID: <184112FE564ADF4F8F9C3FA01AE50009DECDB40ABF@G1W0486.americas.hpqcorp.net>

Jeremy,

Thanks, your explanations were very helpful.  Responses below.

> From: Jeremy Carroll [mailto:jjc@hpl.hp.com]
> [ . . . ]
> Booth, David (HP Software - Boston) wrote:
>
> > 1. It relies on a corner feature of RDF/XML, though perhaps
> > it is only a corner feature to me. Maybe to others it is a
> > central feature. :)
>
> I think it is intended to allow the sort of usage I was
> envisaging of a specialist sub-dialect that can still use the
> extensibility of RDF/XML, while being in another namespace,
> which also as some control.

That section of the RDF/XML spec says:
http://www.w3.org/TR/rdf-syntax-grammar/#start

        "If the content is known to be RDF/XML by context, such
        as when RDF/XML is embedded inside other XML content,
        then the grammar can either start at Element Event
        RDF . . . or at production nodeElementList . . . ."

But the RDF/XML + GRDDL approach feels more like it is doing the opposite: embedding some special XML in an otherwise RDF document.  However I guess it depends on whether the document as a whole is served as application/rdf+xml or application/xml (with a non-RDF root namespace).  If it is served as application/xml with a POWDER namespace, then it looks fine to me, because the document as a whole is clearly *not* RDF/XML (even though it may happen to contain some embedded RDF/XML) and its semantics are entirely determined by the POWDER spec, which is free to delegate to the RDF/XML spec to define the semantics of the embedded RDF/XML portion.

I *do* think the extensibilty of being able to add arbitrary RDF metadata would be a good thing, and I did not include that in the XML + GRDDL approach I previously suggested, but it would be easy to extend it to do so.  For example, a POWDER document might be served as application/xml and look something like:

<powder:powder ... >
  <powder:lite>
    [Standard POWDER Lite goes here]
  </powder:lite>
  <powder:additionalMetadata>
    [Any additional unconstrained RDF/XML goes here]
  </powder:additionalMetadata>
</powder:powder>

The "[Standard POWDER Lite goes here]" part could be required to be a constrained form of RDF/XML, so that it can either be interpreted directly as RDF or processed as XML.  Or, if more conciseness is desired, the POWDER spec could make that portion be a POWDER-specific XML format.  Also, POWDER lite processors could ignore everything inside the <powder:powder:additionalMetadata>...</powder:powder:additionalMetadata> tags if they wanted.  And again, the powder namespace document would provide a GRDDL transformation to determine the entire semantics of the document.

Benefits:
 - clear semantics;

 - easily processable by XML-only apps;

 - easily processable by RDF apps (through the GRDDL transformation); and

 - easily extensible.

> [ . . . ]
> Note that because of the complicated nature of the formal
> meaning, the GRDDL result is more complicated than the original
> document, and in my preferred design, in which the original
> document is in RDF/XML the GRDDL result is not entailed by it -
> but is a faithful rendition of the intent of a powder document
> author - who is principly guided by the operational semantics.

In that case I think it is important that the document be served as application/xml with a POWDER root namespace, instead of application/xml+rdf.

However, can you shed some light on *why* the GRDDL result is not entailed by the original RDF?  Could entailment be used instead of GRDDL processing?


Thanks


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
Received on Thursday, 24 January 2008 21:38:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2008 21:38:20 GMT