Re: attempting to tackle ACTION-514

yes, it can be done in this way, I just left them there to point that these
are the variables in the pattern that are returned. If you think that SELECT
* is clearer I will change the document to that.

Carlos

2011/9/27 Polleres, Axel <axel.polleres@deri.org>

> >  Regarding the algorithm in section 3.1 it comes from section 18.2.2.5 in
> the main query documtent,
> > there is just a new case which is SERVICE.
>
> Would it be a problem to put the whole algorithm and just mark the new part
> with bold face?
>
> > These are the variables which will be returned as a Select vars is done
>
> So, why can't it then be jsut treated (on the level of the definition) as
> 'SELECT *' (then you don't have to explain all that or do I miss something?
>
> Axel
>
> --
> Dr. Axel Polleres
> axel.polleres@deri.org    http://www.polleres.net/
>
> ________________________________
>
> From: Carlos Buil Aranda [mailto:cbuil@fi.upm.es]
> Sent: Mon 26/09/2011 21:23
> To: Polleres, Axel
> Cc: Gregory Williams; SPARQL Working Group
> Subject: Re: attempting to tackle ACTION-514
>
>
> Hi Axel and sorry for this late reply.
>
> during all the emails between Greg and me I've been trying to fix the
> problems that Greg saw in the document. His main concern was in the SERVICE
> VAR section, in which the algorithm was evaluated using a bottom up
> approach. Using that approach it was not possible to assure that a variable
> was bound or not. So me marked the section as informative, not providing the
> definition section. Apart from that, the other main issue remaining was the
> one aboutthe IRI that you answered before.
>
> Regarding the algorithm in section 3.1 it comes from section 18.2.2.5 in
> the main query documtent, there is just a new case which is SERVICE.
>
> Regarding what "the set of variables in-scope in pattern P" means, that
> means the variables that are in pattern P which is evaluated inside the
> SERVICE. These are the variables which will be returned as a Select vars is
> done.
>
> I uploaded the changes you suggested to the CVS.
>
> Carlos
>
>
> 2011/9/20 Axel Polleres <axel.polleres@deri.org>
>
>
>        Carlos, Greg,
>
>
>        I had another look on Greg's comments on Fed-Query as per the thread
> starting at
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JulSep/0007.html
>        going upto:
>
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JulSep/0035.html
>        and
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JulSep/0165.html
>
>        Admittedly, I am a bit confused now (probably just because I haven't
> tackled that earlier and seem to
>        have difficulties recunstructing the "history" here)... when I look
> at section 3.1 in the current incarnation of
>          http://www.w3.org/2009/sparql/docs/fed/service
>        it seems, some of the things referred to in the mail thread seem to
> be lost... Am I missing something? Looking at the right version?
>
>        Particularly, as for
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JulSep/0035.html,
> I am not sure anymore whether all that is referred to
>        in this email is still in the current draft... Can you
> summarize/explain again in one mail what is the exact remaining issue? For
> me,
>        the "algorithm" in section 3.1 is in its current state quite
> confusing and not really clear.
>
>        As for Section 3.2 and the comment in
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JulSep/0165.html
>
>        > "The evaluation of Service is defined in terms of the SPARQL
> Results [RESULTS] returned
>        > by a SPARQL Protocol [SPROT] execution of the nested graph
> pattern"
>        >
>        > The "RESULTS" link is to the XML Results document. Can it be
> defined also in terms of the (new) JSON Results document?
>
>        Well, I think this is anyways a bit tricky.
>        eval() is the evaluation of an algebra expression with respect to an
> active graph... so, it is supposed to return a
>        multiset of solution mappings, whereas this sentence seems to
> suggest that we are talking about an XML results document here. Also I find
> the
>         if IRI
>        in the definition a bit strange
>        ... I suggest to let go of the pseudo-algorithm for "Definition:
> Evaluation of a Service Pattern" in Section 3.2
>        and just write it in more natural language:
>
>        -------------------------------
>        The evaluation of Service is defined in terms of the multiset of
> solutions corresponding to the result returned by a SPARQL Protocol [SPROT]
>        execution of the nested graph pattern against a SPARQL endpoint:
>
>         Definition: Evaluation of a Service Pattern
>
>         Let
>            - iri be an IRI,
>            - vars be the set of variables in-scope in pattern P,
>            - ?0 the solution set with one empty solution, and
>            - SilentOp be a boolean variable to indicate that SERVICE
> execution should ignore errors when true.
>
>         Then:
>           eval(D(G), Service(IRI,P,SilentOp)) = Invocation( iri, vars, P,
> SilentOp )
>
>        where: Invocation(IRI, Vars, P, SilentOp) is
>            * the multiset of solution mappings corresponding to the results
> of executing query
>             SELECT Vars WHERE P against the service endpoint with IRI iri,
> in case of a successful service invocation according to the SPARQL protocol,
> and otherwise
>            * ?0, in case SilentOp is true, and otherwise
>            * err
>        -------------------------------
>
>        What is still not quite clear to me is what "the set of variables
> in-scope in pattern P" exactly means, can you clarify?
>
>        Axel
>
>
>
>
>
>
>
>