- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 26 Jan 2006 09:55:06 -0600
- To: andy.seaborne@hp.com
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>, Enrico Franconi <franconi@inf.unibz.it>
>Enrico Franconi wrote: >>On 25 Jan 2006, at 20:42, Pat Hayes wrote: >>>Wait: G' is not required to be the same graph as G, even in basic >>>SPARQL. If we do that, then we get compulsory told bnodes for all >>>conforming engines. So the IRIs and literals in G and G' are the >>>same, but the bnodeIDs might be (should be, IMO) different. In >>>more direct language, the answer set can have (has) a different >>>bnode scope than the dataset graph. >> > >Through out this, isn't it s/IRI/blank node label/? No. Since the definitions talk about unions, all the triples are being treated there like they are in one big graph, so you can't have different bnodes with the same bnode label. Thats why we have to be very careful about what is standardized apart from what. >>We have two options here: >> >>1) The current text says that a standard SPARQL engine (say, of >>type A) should return the same IRIs as in the original graph. >>According to my (limited) sampling of the available >>implementations, engines of type A are the vast majority of >>existing engines (I found only one not returning the same IRIs, >>probably done via a post-process of renaming); this shows that >>actually it is easier for implementations to return the same IRIs >>as in the original graph (it actually is: it is just a subgraph >>matching after all). > >ARQ is type A locally and type B remotely. Right, that is exactly appropriate IMO. >>Engines (say, of type B) which do not necessarily return the same >>IRIs as in the original graph will still be SPARQL-compliant >>extensions of SPARQL: they have just to declare their different >>semantics (where G is not necessarily equal to G'). This was the >>aim of our (successful, so far) game on the parametric semantics: >>to define a framework were it is possible/necessary to formally >>define the semantics of the extension in order to be called >>SPARQL-compliant. >>This is my favourite choice. >> >>2) The dual option is of course a standard SPARQL where engines (of >>type B) do not *necessarily* return the same IRIs as in the >>original graph. This is obtained by deleting the condition that in >>standard SPARQL G=G'. Engines (of type A) which do return the >>same IRIs as in the original graph will still be standard SPARQL >>engines (i.e., engines of type A would be also engines of type B), >>but users wouldn't know that *in addition* they preserve IRIs >>names. Engines may *optionally* declare themselves as >>SPARQL-compliant extensions of SPARQL: they have just to declare >>their different semantics (i.e., G=G'). This case is bizzarre >>since after all engines of type A are also engines of type B (the >>standard ones), so implementors may tend not to declare the >>different semantics. >> >>Andy, what do you think? > >It is important to note that the XML result set format also scopes >blank node labels to the result set. Over the wire, it's always type >B. But that is regardless of whether G=G'. No, its not. If the definitions require G=G', then scoping answer bnodes to the result document is wrong, so our XML result set definition would be illegal. The definitions require answer bnodes to be in the same scope as G', so if they are scoped separately from G in the XML then G' must be bnode-distinct from G in that case. >What local query does is a local matter and not covered by the spec. A local query can be processed on the basis that G'=G, which is a legal option, and then 'told bnodes' will work at the local level, which is also legal. So this is covered by the spec. Or, if you think it shouldn't, then the right thing to say is that G' is equivalent to G but shares no bnodes with G at all. But I see no harm in leaving the flexibility in the definitions, to allow local query processing to be conformant, with or without told bnodes, so long as it doesn't use the XML output format. Pat > > Andy > >> >>cheers >>--e. -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Thursday, 26 January 2006 15:55:23 UTC