Re: xsd:hexBinary and xsd:base64Binary entailments

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/

Received on Tuesday, 6 December 2011 13:53:38 UTC