Re: xsd:hexBinary and xsd:base64Binary entailments

On 8 Dec 2011, at 12:05, Birte Glimm wrote:

> Henry,
> 
> Thank you for your comment about D-Entailment Regime.
> 
> In the current editor's draft, the D-Entailment Regime no longer
> prescribes a fixed datatype map. Thus, systems that implement the
> D-Entailment Regime are free to support xsd:hexBinary and
> xsd:base64Binary.
> 
> The current editor's draft is available at:
> http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml
> 
> Regarding your example query, the answer would indeed be true if the
> queried endpoint supports the D-Entailment Regime and includes
> xsd:hexBinary in its datatype map. In this case, the query answers are
> determined based on the data values and not on the lexical forms and
> white space does not change the actual data value.
> 
> As you suggest, it would also be possible to use SPARQL endpoints that
> do not support D-entailment, provided that users & applications use
> only use canonical forms of literals, e.g., without whitespace.
> 
> We would be grateful if you would acknowledge that your comment has
> been answered by sending a reply to this mailing list.

Thanks a lot for the answers. Your comments do answer the questions I had.

All the best,

	Henry

> 
> Birte, on behalf of the SPARQL-WG
> 
> On 6 December 2011 14:52, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 3 Dec 2011, at 19:40, Birte Glimm wrote:
>> 
>>> Hi Henry,
>>> 
>>> this is not a formal reply yet (which needs agreement with the WG),
>>> but I quickly wanted to comment to make sure I now understand your
>>> comment.
>>> 
>>> In short, I assume your points are mainly:
>>> a) Your critise that the datatype map of the D-Entailment Regime in
>>> SPARQL 1.1 Entailment Regimes does not include xsd:hexBinary and
>>> xsd:base64Binary, right?
>> 
>> yes, the worry I had was that as they were not listed I was wondering
>> if xsd:hexBinary and xsd:base64Binary were  the right things to
>> D-entail each other? It seemed that they should, but I was wondering
>> why they had been left out.
>> 
>> 
>>> b) Your ask whether a the given Boolean query would be answered with
>>> true by systems that support D-entailment with the two datatypes or at
>>> least with xsd:hexBinary.
>> 
>> Just for context, the boolean query is found on
>> http://webid.info/spec#verifying-the-webid-claim
>> 
>> PREFIX : <http://www.w3.org/ns/auth/cert#>
>> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
>> ASK {
>>   <https://bob.example/profile#me> :key [
>>      :modulus "cb24ed85d64d794b69c701c186acc..."^^xsd:hexBinary;
>>      :exponent 65537;
>>   ] .
>> }
>> 
>> yes, though there are perhaps a few subquestions here:
>> 
>>  1) should a query on a system that did not support D-entailment return
>>   true if the data for the hex number had leading or ending white spaces
>>   in it or will  that require D-entailment just on xsd:hexBinary to be specified
>> 
>> i.e. if the data were
>> 
>> <https://bob.example/profile#me> :key [
>>  :modulus """
>>      cb24ed85d64d794b69c701c186acc...
>>          """^^xsd:hexBinary;  #notice the white space
>>  :exponent 65537;
>> ] .
>> 
>> 
>>  2) will one in the future be able to ask that systems support
>>    D-entailment for hexBinary and base64Binary, in such a way that either
>>    notation could be used
>> 
>> 
>>> 
>>> Regarding a), note that we are going to a second last call phase in
>>> which several changes have been made to the D-entailment regime. An
>>> important change is that the spec no longer prescribes a fixed
>>> datatype map. It is now up to implementations of the regime to specify
>>> (e.g., in their documentation), which datatype map they assume. Thus,
>>> systems can now support xsd:hexBinary and xsd:base64Binary under the
>>> D-Entailment Regime.
>>> You can see that editor's version of the spec incl. these changes at:
>>> http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml
>> 
>> Ok, thanks.
>> 
>>> 
>>> b) For systems that support the D-Entailment Regime with a datatype
>>> map that includes xsd:hexBinary (or both datatypes in question), the
>>> query answers are determined based on the data values and not on the
>>> lexical forms. Since whitespace in the lexical form does not change
>>> the data value, a system would behave as you want it and answer the
>>> query with true
>> 
>> ok, so it looks like we do need to at least specify D-entailment on
>> xsd:hexBinary in our spec .
>> 
>>> .
>>> 
>>> Regarding the phrasing in your spec:
>>> http://www.w3.org/2005/Incubator/webid/spec/#verifying-the-webid-claim
>>> I don't see a paragraph mentioning D-entailment yet, but it seems most
>>> appropriate to say something like "We assume that the queried SPARQL
>>> endpoint employs the D-Entailment Regime [reference] with a datatype
>>> map that includes [datatypes you need, e.g., xsd:hexBinary and
>>> xsd:base64Binary]".
>> 
>> thanks. I think we can leave xsd:base64Binary for later, because we would
>> first need to check how many systems actually support it. (We don't want
>> to ask for things that are not practically feasible - and this is where having
>> those in the SPARQL spec could have helped us).
>> We can then add it later, especially if we find that GRDDLing XML-DSIG turns
>> out to be popular.
>> 
>> Thanks for your detailed answers.
>> 
>>   Henry
>> 
>> PS this is part of our ISSUE-61: xsd datatypes
>>   https://www.w3.org/2005/Incubator/webid/track/issues/61/
>> 
>>> Best regards,
>>> 
>>> Birte
>>> 
>>> 
>>> 
>>> On 30 November 2011 16:48, Henry Story <henry.story@bblfish.net> wrote:
>>>>> Hi all,
>>>>> 
>>>>> I am a bit surprised that this mail didn't go to the comments list. As
>>>>> I understand it, it is more meant to be a comment.
>>>> 
>>>> Ah yes. I just now realised that the best way to find the mailing list to reply to
>>>> is to look at the specs.
>>>> 
>>>>> I put some thoughts below only sending it to the SPARQL list so far as I am not sure
>>>>> whether this is a SPARQL member list mail (the author is not a WG
>>>>> member or did we just never meet?) or to be treated as a comment with
>>>>> all the formalities that this brings.
>>>> 
>>>> It's probably better for the comments list. I am sending this there.
>>>> 
>>>>> Birte
>>>>> 
>>>>> On 30 November 2011 00:49, Henry Story <
>>>>> henry.story@bblfish.net
>>>>>> wrote:
>>>>>> Dear SPARQL group,
>>>>> [snip]
>>>>>> 1. xsd:hexBinary and white space
>>>>>> ================================
>>>>>> 
>>>>>> We are hoping to have WebID deployed very widely to authenticate people across a vast number of resources. So we do need
>>>>>> the SPARQL query to be flexible.
>>>> 
>>>> For the context in the new mailing list, we are speaking of the ASK query in the WebID spec as mentioned in
>>>>  http://webid.info/spec
>>>> 
>>>>> Using Jena arc I found that an xsd:hexBinary query on an RDF document containing a
>>>>>> white space in the data, does not give the right result:
>>>>> 
>>>>> [snip example which appears in Jena-170 bug report]
>>>>> 
>>>>>> I filed a bug report on the list and the conclusion seems to be that Jena
>>>>>> is working according to spec.
>>>>>> 
>>>>>> 
>>>>> https://issues.apache.org/jira/browse/JENA-170
>>>>> 
>>>>> Yes, and the discussion there pretty much explains the point.
>>>> 
>>>> well the issue is explained and the question is: if the SPARQL there is working according to
>>>> spec, then it is not intuitive, and could lead to issues appearing in people verifying their WebIDs,
>>>> with data that could be understood to be compliant.
>>>> 
>>>>>> I suggest that this be defined more clearly in the SPARQL D-entailment section of the spec.
>>>>> 
>>>>> Ok, here's some confusion. What does "SPARQL D-entailment section of
>>>>> the spec" refer to?
>>>> 
>>>> http://www.w3.org/TR/sparql11-entailment/#DEntRegime
>>>> 
>>>> It does not mention either xsd:hexBinary or xsd:base64Binary .
>>>> 
>>>> As we are writing a spec we need to understand what
>>>> 
>>>> 
>>>>> The Query spec? There is no such section in the
>>>>> query spec, exactly for the reason that the Query spec assumes simple
>>>>> entailment/subgraph matching. Thus, no understanding of datatypes. A
>>>>> system that supports D-Entailment with the mentioned datatypes (as per
>>>>> D-Entailment Regime in the SPARQL Entailment Regimes spec) would
>>>>> behave as expected. The problem is rather that it is expected from
>>>>> systems that do not support D-Entailment that they have understanding
>>>>> of datatypes. I don't think the Entailment Regimes spec needs
>>>>> clarification since with D-Entailment, the system would do as the user
>>>>> expects. I also don't think that the Query spec needs clarification
>>>>> since simple entailment/subgraph matching just does not support
>>>>> D-entailment and that was never claimed.
>>>> 
>>>> Ok, so should we just say in section 3.2.4.2 "Verifying the WebID Claim" of
>>>> 
>>>>  http://www.w3.org/2005/Incubator/webid/spec/#verifying-the-webid-claim
>>>> 
>>>> that we are speaking of a D-entailment compliant SPARQL engine? That's ok.
>>>> But does that make xsd:hexBinary with and without initial white spaces equivalent?
>>>> 
>>>>> 
>>>>>> 2. xsd:hexBinary and xsd:base64Binary
>>>>>> =====================================
>>>>>> 
>>>>>> We are using xsd:hexBinary because there is no xsd:hexInteger which we would have suited us more correctly. We are using xsd:hexBinary because hex is what most tools use. The XML D-SIG spec uses what seems to be the equivalent of xsd:base64Binary named there a ds:CryptoBinary
>>>>>> 
>>>>>> 
>>>>> http://www.w3.org/TR/xmldsig-core/#sec-CoreSyntax
>>>>> 
>>>>>> 
>>>>>> So thinking a bit longer term it would be very useful if a simple GRDDL of such a document could produce a graph that can be queried with the same ASK query defined in the WebID spec. For that there needs to be a D-entailment relation between xsd:hexBinary and xsd:base64Binary. There is no reason there should not be such an entailment, since obviously both are binaries - they are just encoded differently.
>>>>> 
>>>>> Systems that support D-Entailment with xsd:hexBinary and
>>>>> xsd:base64Binary datatypes would recognise that the two datatypes have
>>>>> the same vlue space, just with different lexical form. Thus, what is
>>>>> desired is broader D-entailment support. That doesn't justify calling
>>>>> a non-D-entailment system incorrect or buggy IMO. One could just
>>>>> complain that there are not enough systems that support D-entailment
>>>>> for the mentioned datatypes. Another issue might be that D-entailment
>>>>> is an extension of RDFS-entailment, so unless SPARQL invents its own
>>>>> entailment relations (somehow by arguing that D-entailment in its
>>>>> current form is a mistake) D-entailment will always also imply
>>>>> RDFS-entailment, which might or might not be desired in such systems.
>>>> 
>>>> Ok, I am just trying to figure out how we can write our spec correctly.
>>>> Clearly our users will need D-entailment supported systems, or else they will
>>>> be having difficult to debug false negatives.
>>>> 
>>>> 
>>>> Henry
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> All the best,
>>>>>> 
>>>>>>        Henry Story
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Social Web Architect
>>>>>> 
>>>>> http://bblfish.net/
>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
>>>>> Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
>>>>> University of Ulm                         Fax:   +49 731 50 24188
>>>>> D-89069 Ulm
>>>>> birte.glimm@uni-ulm.de
>>>>> 
>>>>> Germany
>>>>> 
>>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
>>> Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
>>> University of Ulm                         Fax:   +49 731 50 24188
>>> D-89069 Ulm                               birte.glimm@uni-ulm.de
>>> Germany
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> 
> 
> -- 
> Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
> Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
> University of Ulm                         Fax:   +49 731 50 24188
> D-89069 Ulm                               birte.glimm@uni-ulm.de
> Germany

Social Web Architect
http://bblfish.net/

Received on Thursday, 8 December 2011 11:11:24 UTC