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

RE: Multiple GRDDL results in a single transform??? GRDDL and Named Graphs

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Thu, 24 Jan 2008 04:31:51 +0000
To: Jeremy Carroll <jjc@hpl.hp.com>
CC: "public-grddl-wg@w3.org" <public-grddl-wg@w3.org>, "patrick.stickler@nokia.com" <patrick.stickler@nokia.com>, "chris@bizer.de" <chris@bizer.de>, Phil Archer <parcher@icra.org>
Message-ID: <184112FE564ADF4F8F9C3FA01AE50009DECDAEA0DA@G1W0486.americas.hpqcorp.net>

Thanks, the examples are quite helpful.  I was not aware that it was possible to do that with RDF/XML.

While I definitely think a GRDDL-based approach is a good way to go, there are a couple of aspects of doing a GRDDL transformation of RDF/XML to produce more RDF that make me uncomfortable.

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.  :)

2. It makes the semantics of an RDF/XML document less clear, because to a non-GRDDL aware receiver, the document conveys only the triples directly serialized in the RDF/XML, whereas to a GDDL-aware receiver, it conveys additional triples.  If a document is served as application/rdf+xml, the recipient should be able to look at the RDF/XML spec to determine its semantics.  But the RDF/XML spec does not reference the GRDDL spec.

To an extent, we can finesse this ambiguity by recalling GRDDL's "faithful rendition" clause
http://www.w3.org/TR/grddl/#sec_rend
and taking the position that if the additional triples from the GRDDL transformation are all *entailments* from the base triples, then the resulting merged set of triples could legitimately be viewed as a "faithful rendition" of the original document.  However, that is very error prone, because essentially the same information is being conveyed in two different ways: once through the directly serialized triples and their entailments, and again through the GRDDL results.

So regarding POWDER, I would be quite uncomfortable with POWDER using this RDF/XML + GRDDL approach.  I also don't see any benefit to it over an XML + GRDDL approach.  To be clear, by an "XML + GRDDL" approach I mean: define POWDER in terms of abstract RDF, but also define a custom XML format whose semantics are *entirely* defined by the RDF resulting from its GRDDL transformation.  This would give the combined benefits of:

 - a concise XML serialization for those who want it, so XML tools can be used if desired;

 - clear semantics (given by GRDDL-generated RDF); and

 - compatibility with the Semantic Web, so standard RDF tools can also be used.

Regarding GRDDL, I think it was a mistake to include that feature in the GRDDL spec.  I think it would have been better to say that the GRDDL results of an RDF/XML document -- or any other RDF serialization, for that matter -- are *only* the RDF graph represented by that document.

In any event, GRDDL test case http://www.w3.org/TR/grddl-tests/#grddlonrdf is clearly flawed and should be corrected or deleted in an erratum, because the GRDDL spec at
http://www.w3.org/TR/grddl/#rule_rdfxbase
talks about a "conforming RDF/XML document"
http://www.w3.org/TR/grddl/#rule_rdfxbase
but, assuming the RDF Validator is correct, the input of that test case is not a conforming RDF/XML document.


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.


> -----Original Message-----
> From: Jeremy Carroll [mailto:jjc@hpl.hp.com]
> Sent: Wednesday, January 23, 2008 6:00 AM
> To: Booth, David (HP Software - Boston)
> Cc: public-grddl-wg@w3.org; patrick.stickler@nokia.com;
> chris@bizer.de; Phil Archer
> Subject: Re: Multiple GRDDL results in a single transform???
> GRDDL and Named Graphs
>
> Booth, David (HP Software - Boston) wrote:
>
> > Can you please show an example?  If the input for test case
> > http://www.w3.org/2001/sw/grddl-wg/td/grddl-tests#grddlonrdf
> > were converted to this form, what would it look like?
> >
> Sorry for delay in replying ...
> http://www.w3.org/2001/sw/grddl-wg/td/grddlonrdf.rdf doesn't include a
> typed node ...
>
> This means that we can't use the namespace doc method but
> (referring to
> http://www.w3.org/TR/rdf-syntax-grammar/#start
> )
> We can serve the following doc with mimetype application/rdf+xml:
>
> <rdf:Description
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:foaf="http://xmlns.com/foaf/0.1/"
> xmlns:con="http://www.w3.org/2000/10/swap/pim/contact#"
> xmlns:data-view="http://www.w3.org/2003/g/data-view#"
> data-view:transformation="foaf2con.xsl"
> rdf:about="http://musicbrainz.org/mm-2.1/album/6b050dcf-7ab1-4
> 56d-9e1b-c3c41c18eed2">
> <foaf:maker>
> <foaf:Agent
> rdf:about="http://musicbrainz.org/mm-2.1/artist/33b3c323-77c2-
> 417c-a5b4-af7e6a111cc9">
> <foaf:name>The Jimi Hendrix Experience</foaf:name>
> </foaf:Agent>
> </foaf:maker>
>
> </rdf:Description>
>
> This has one extra triple over and above the original, since the
> data-view:transformation is treated as a property attribute.
>
> Adding a type triple instead, we could also serve the
> following as rdf/xml:
>
>
> <eg:DummyType
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:foaf="http://xmlns.com/foaf/0.1/"
> xmlns:con="http://www.w3.org/2000/10/swap/pim/contact#"
> xmlns:eg="http://example.org/namespace#"
> rdf:about="http://musicbrainz.org/mm-2.1/album/6b050dcf-7ab1-4
> 56d-9e1b-c3c41c18eed2">
> <foaf:maker>
> <foaf:Agent
> rdf:about="http://musicbrainz.org/mm-2.1/artist/33b3c323-77c2-
> 417c-a5b4-af7e6a111cc9">
> <foaf:name>The Jimi Hendrix Experience</foaf:name>
> </foaf:Agent>
> </foaf:maker>
>
> </eg:DummyType>
>
> And at http://example.org/namespace.rdf we have a namespace doc
> including the triple
>
> <http://example.org/namespace#>
>   dataview:namespaceTransformation
>   <????/foaf2con.xsl> .
>
> Jeremy
>
>
>
>
>
>
>
Received on Thursday, 24 January 2008 04:33:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2008 04:33:39 GMT