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

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

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

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

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

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

Received on Wednesday, 30 November 2011 10:07:04 UTC