- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Fri, 12 Dec 2008 15:58:47 +0000
- To: Danny Ayers <danny.ayers@gmail.com>
- CC: Dan Connolly <connolly@w3.org>, public-grddl-comments <public-grddl-comments@w3.org>, Tim Berners-Lee <timbl@w3.org>
Hi Danny, Regarding TimBL's request for "full GRDDL results" http://lists.w3.org/Archives/Public/public-grddl-comments/2008AprJun/0067.html I just noticed that I never replied to your message below. Sorry! Here are answers. > From: Danny Ayers [mailto:danny.ayers@gmail.com] > > This notion appeals very much in principle, but I'm a little > unsure of how it might work and/or provide benefits in > practice, essentially due to the possibility of more > convoluted operations than xml -xslt-> rdf > > These may be foolish questions, so kindly consider me Devil's > Duty Solicitor - > > How does one know one has the complete GRDDL results? 1. The notion of "complete GRDDL results" needs to be defined by the GRDDL specification (or related spec) so that it has a standard, unambiguous meaning. 2. The GRDDL processor needs to indicate whether or not the set of results it produced are known to constitute the complete GRDDL results. There will be two usual cases: - The set of results *is* known to be the complete GRDDL results; or - The set of results is *not* known to be the complete GRDDL results. It *may* be complete, but there is no guarantee of completeness, because a potential source of additional triples was not followed. For example, the complete transitive closure of namespace dereferencing was not performed, or a GRDDL transformaiton was not executed for security reasons. > > From a producer's point of view it should be relatively > straightforward to confirm that all the correct chains have > been followed. > > But from a consumer's point of view, what checks can they > realistically put in place to ensure they're getting the full > picture? It seems they are essentially in pretty much the > usual open world kind of situation, they may miss statements > thanks to an error code somewhere down the line - or should > we expect GRDDL-aware processors to notify the client of such > circumstances? The point is not exactly to ensure that the complete GRDDL results *will* always be obtained. As you rightly point out, there can be no guarantee of that. Rather, the point is to ensure that a consuming application has a well-defined way to know whether the complete GRDDL results *were* obtained, so it can take appropriate action if it knows that triples may be missing. > > Back to the producer, if a (quasi-)static complete GRDDL > result is readily available, what motivation have they to go > down the GRDDL path, rather than simply <link alternate=... > or conneg'ing to an RDF/XML representation? I think the reasons would be similar to other cases where GRDDL is helpful. GRDDL allows the document owner to maintain a single, master XML document while off-loading, to the client, the processing needed to generate the alternate RDF for it. David Booth
Received on Friday, 12 December 2008 16:15:05 UTC