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

This chimes with the sort of discussion that has been going on within 
the POWDER WG and its predecessors. The very tentative test data I 
created earlier this week [1] offers 4 examples written in "operational 
POWDER" (DR-O) as RDF/XML and XML, and in "semantic POWDER" (DR-S) with 
both RDF formats also graphed.

I tried to think of a strong reason or use case for using RDF/XML as the 
serialisation for a DR-O and couldn't do so. That doesn't mean there 
aren't any, just that I can't think of one. In the absence of such a 
reason, I tend to agree with David both in reasoning and conclusion that 
an XML dialect for a DR-O is probably safer. Having a DR-O as XML with 
semantics fully defined and available through GRDDL strikes me as a way 
forward that just might please more people than it upsets :-). I believe 
it also handles the conditional aspects? (this data is valid if today is 
between these dates, for example).

The POWDER WG has done a lot of thinking in terms of what the protocol 
needs to do and how it should work operationally. If we can get the 
semantics sorted through this discussion and Jeremy's Wiki page [2], we 
should be in a good position by the end of next week's face to face 
meeting to get new drafts of the documents in the public domain quickly. 
If next week goes well we should be able to go to Last Call next month.

Phil.

[1] http://lists.w3.org/Archives/Public/public-powderwg/2008Jan/0021.html
[2] http://www.w3.org/2007/OWL/wiki/POWDER

Booth, David (HP Software - Boston) wrote:
> 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
>>
>>
>>
>>
>>
>>
>>
> 
> 

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Received on Thursday, 24 January 2008 09:51:15 UTC