Re: xsd:hexBinary and xsd:base64Binary entailments

> 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/

Received on Wednesday, 30 November 2011 15:49:00 UTC