Re: xsd:hexBinary and xsd:base64Binary entailments

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?
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.

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

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.

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]".

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

Received on Saturday, 3 December 2011 18:41:13 UTC