Re: xsd:hexBinary and xsd:base64Binary entailments

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.

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

Received on Thursday, 8 December 2011 11:06:02 UTC