W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: The theoreticians got rid of the OrderedMerge

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 26 Jan 2006 14:42:30 -0600
Message-Id: <p06230912bffee146a773@[10.100.0.23]>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: Enrico Franconi <franconi@inf.unibz.it>, RDF Data Access Working Group <public-rdf-dawg@w3.org>

...
>>
>>>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'.
>>
>>So, you are saying that the protocol disallows any possible 
>>extension  of SPARQL to be of type A remotely as well (so that it 
>>will be able  to answer queries with told bnodes)?
>
>No, not "disallows".  I'm noting that the current text in the XML 
>result set doc says that labels are scoped to the XML file.  The XML 
>file is a standalone unit of information that can be interpreted 
>without reference to anything else.  In particular, two XML results 
>can't be related by blank node labels unless the application/client 
>has some other piece of information.
>
>The labels may have wider scope - they may not - it does not say (I 
>don't read "scoped to XML doc" as "only scoped to XML doc" - an 
>engine can just dump in global, non-IRI identifiers for blank node 
>labels

I don't think that makes sense in terms of the underlying RDF model. 
RDF graph blank nodes really are supposed to be *blank*. The bnodeIDs 
in the RDF/XML are part of the XML serialization, not in the graph 
itself. Since we are defining this particular XML serialization, 
seems to me we are required to say how it is supposed to be read as 
describing RDF: we can't leave it open-ended, particularly as this 
ambiguity is semantically important. An inference engine won't know 
what to do.

>  but clients can't rely on on that fact, or the stablility of them 
>unless the service makes additional information known.

Ah, OK, then this has been a misunderstanding for me all along. Ive 
been assuming that bnodeIDs in an XML answer document must be 
considered to be local to that document.

If not, how can anyone determine what the intended scope of the IDs 
is supposed to be? If it can be extended arbitrarily, there is no 
general way to determine how to combine results from multiple such 
documents. (Do we separate bnodes or not? Only an open-ended search 
for information can tell for sure.)

IMO it would be simpler and clearer to say that XML answer documents 
determine the scopes of their identifiers. This would seem to be in 
line with all other XML useage. This doesn't preclude told-bnode 
transactions in SPARQL engines which communicate answers in other 
ways, which I think gives Enrico his type-A window (and would satisfy 
the UMD requests made earlier).

>
>[[ARQ provides both modes.  The default is blank node labels in the 
>XML file are  allocated for the file (they will start at "b0" IIRC 
>and count up as new bNodes are encounter in the result stream).]]
>
>>Can't we just say that the protocol is neutral, and passes on 
>>whatever data comes from the core local engine? The protocol should 
>>not take any semantic decision, I guess.
>
>I see the results format as being as neutral as possible in it's 
>current form because it gives the minimal requirement (labels only 
>guaranteed to be scoped to the document).
>
>	Andy
>
>>[pls note that I'm quite ignorant about the deep issues involving 
>>the  protocol]
>>I'd just would like to make sure that - if we go with the second 
>>option (the one backed by Pat) - type A extensions will be possible 
>>in the future, while still being somehow 'SPARQL compliant'.
>>I expect many applications immediately asking for type A services.
>>
>>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 20:42:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:25 GMT