- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Sat, 30 Aug 2008 00:36:18 +0100
- To: noah_mendelsohn@us.ibm.com
- Cc: "Ralph R. Swick" <swick@w3.org>, public-rdf-in-xhtml-tf@w3.org
Hi Noah, Many thanks for your excellent comments. To make it easy to discuss things, I'm going to keep this email purely on the issue of default graphs and conformance. Ralph replied to your original comments, like this: >> If the observable behavior of such software is indistinguishable from >> software that does construct the full default graph then it is >> impossible to prove non-conformance and so we would not care. You have replied: > On this one I'm not convinced. Let's say I build a piece of software that > exposes exposes to applications exactly one triple from the graph. That's > all the API I've built can do; it's a special purpose API that returns if > available, say, the email address for some requested principal. The > triple is correct, and so the output is indistinguishable from that which > would be produced by software that first built the whole graph, and then > provided the one triple. The software is useful and it does what my > application needs; it's also easier to write and debug than something > that exposes the whole graph. > > The problem is, your draft says my software is nonconforming. The draft > says that conforming software must "MUST make available to a consuming > application a single [RDF graph] containing all possible triples". My > software fails that test, because it exposes only one triple. To make it > conforming, I have to add APIs to my software that will expose all the > other triples, even though I know that my particular application will > never call for those other triples. I wonder if the layers are being mixed up a bit, here, though. If you parse the entire document, create a complete graph, and then in some "consuming application" make available to some _other_ application only one triple, then I would say that your are "fully conforming". That is because the parser has created a full graph, which is then filtered before being presented to some other layer. But that's very different to your parser only recognising @property="foaf:name", for example, but rejecting all other predicates. I'm not sure in what sense that could be called "fully conforming", even if in some situations it might be very useful. The related scenario we wanted to protect against was where a parser produced _too many_ triples. We felt that it was leaving RDFa open to being watered-down, and fragmented, if we allowed additional triples to be added to the default graph without the syntax driving those triples being part of the standard. However, parsers are free to create _additional_ graphs, and this is what leaves the door (wide) open for experimentation. Regards, Mark -- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Received on Friday, 29 August 2008 23:36:55 UTC