- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 9 Dec 2011 10:24:04 +0100
- To: Stéphane Corlosquet <scorlosquet@gmail.com>
- Cc: WebID XG <public-xg-webid@w3.org>
- Message-Id: <4BAC8D53-C894-4ABE-98AF-CFA94FEA2BD6@bblfish.net>
On 9 Dec 2011, at 05:26, Stéphane Corlosquet wrote:
> Henry,
>
> On Thu, Dec 8, 2011 at 7:16 AM, Henry Story <henry.story@bblfish.net> wrote:
> I have now added D-entailment support requirement as a MUST to the spec,
> and since few SPARQL endpoints support it, I have also added a programmatic
> description of how to get the same result without SPARQL. ( Jena does not
> support D-entailment for example )
>
> You have introduced the notion of triple store in the spec. It reads "For verifiers that do not have access to a SPARQL query engine but that do have access programmatically to a triple store"
>
> I believe you meant RDF stack or RDF library here. WebID does not require a triple store.
Yes, not sure which of those two is better to use. We need some kind of graph object that can be queried
programatically.
Henry
>
> Steph.
>
>
> http://bblfish.net/tmp/2011/12/06/index-respec.html#verifying-the-webid-claim
>
> The diff is here:
>
> https://dvcs.w3.org/hg/WebID/rev/a5b20104919b
>
> Henry
>
> PS. Brite would you like me to also post that to the sparql group, so they can
> see the result of the question?
>
>
> On 8 Dec 2011, at 12:05, Birte Glimm wrote:
>
> > 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
>
> Social Web Architect
> http://bblfish.net/
>
>
>
Social Web Architect
http://bblfish.net/
Received on Friday, 9 December 2011 09:24:40 UTC