- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Thu, 8 Sep 2005 11:19:55 -0400
- To: Dan Connolly <connolly@w3.org>
- Cc: public-rdf-dawg@w3.org, jos.deroo@agfa.com, public-rdf-dawg-request@w3.org, andy.seaborne@hp.com, Enrico Franconi <franconi@inf.unibz.it>
On Sep 8, 2005, at 9:32 AM, Dan Connolly wrote: > On Thu, 2005-09-08 at 12:55 +0200, Enrico Franconi wrote: >> On 8 Sep 2005, at 10:37, Seaborne, Andy wrote: >>> For SPARQL to be useable, it must be possible to make queries >>> against the exact triples in the base data. I think there is no question about this. Or, I hope there isn't :) [snip] >> The point I am raising is in the case you want to be compliant with >> RDF MT, which seems to me necessary for SPARQL: we don't want SPARQL >> to be unable to correctly answer queries under the official standard >> RDF-MT semantics. > > The WG doesn't have any requirement along those lines, so you're > presuming a bit when you write "we don't want...". You're presuming a bit that he didn't just mean me as well as him :) I would also argue that it's implicit in the charter. I think the "subgraph the deductive closure" is a viable strategy overall, if, as I've said, not to my taste, but there are issues that crop up as soon as you even consider RDF entailment. Resolving these I think will make SPARQL for RDFS and OWL easier. (At the very least, we need to be clear what counts as dataset and result equivalence.) > Meanwhile, > I found the way PFPS phrased the argument pretty compelling: > > [[ > For example, an RDF implementation that > leans (RDF Semantics, Section 0.3) any graph it stores can > interoperate with > one that doesn't. ... However, such interoperating RDF implementations > cannot > become interoperating SPARQL implementations. > ]] > -- > http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/ > 0038.html Very nice post. He raises good points about BNodes. I feel both ways. If you are trying to remotely navigate an RDF Document (e.g., for a remote editing or browsing implementation) you *NEED* to be able to maintain session information wrt bnodes (as we've argued; I'm not arguing for sessions here, just pointing out that there are a class of use cases that require exposure of some (abstract) implementation details). OTOH, it does go against the spirit of the semantics. Of course, my conclusion is to avoid Bnodes in data *especially* to cover for syntactic inadquacies (which, I believe, is what's happening in FOAF and OWL :(). Cheers, Bijan.
Received on Thursday, 8 September 2005 15:20:21 UTC