Re: fed review

  Thaks Greg for your comments and sorry for  the delay in answering them.

On 05/07/2011 10:35, Gregory Williams wrote:
> Section 2.2
>
> I think it would be a much simpler example if the SERVICE blocks weren't nested.
I agree, but the original idea was to allow them, and since we can have 
subqueries in which SERVICE is allowed I do not know why nested SERVICE 
couldn't be there. Besides, this is an optional extension of SPARQL 1.1 
and implementors should warn of what they implement in their systems. 
So, I prefer to keep it.
> Section 3.1
>
> "Let G := Join(G, Service(VAR, G, Transform(P), SilentOp))"
>  I don't think this works, as the evaluation semantics should try to evaluate the Service() pattern without access to the results of evaluating the G pattern (which are needed to bind VAR)
I do not completely understand what you mean.
> "if IRI is a service URL"
> "if IRI is a SPARQL service"
>  How do I know if it's a SPARQL service URL or just some other URL?
You can't, users are reponsible of knowing what they query in the same 
way users should know what data they want to query in a SELECT
> "eval(D(G), Service(IRI,G,P,SilentOp)) = Invocation( IRI, vars, P, Bindings(G, vars), SilentOp )"
>  Where does 'vars' come from here?
it comes from the definition header:
Definition: Evaluation of a Service Pattern

     if IRI is a service URL and vars is the set of variables in-scope 
in pattern P, Ω0 a solution set with one empty solution.

> "foreach i in Ω(?var->i)"
>  Where does Ω come from in this definition? I think it's meant to refer to results from a join that is outside the scope of this operation.
yes, I will make that explicit.
> "Definition: Evaluation of a Service Pattern"
>  This defn. doesn't seem to use the SilentOp flag as described. It looks like it only affects evaluation if VAR is bound to a non-IRI?
I think you are right.
>  The indentation in this defn. is confusing (the depth of if/else statements aren't balanced, but they don't explicitly close with, e.g., a "done" statement)
yes, I will add done for making explicit that
> "where: Invocation(IRI, S, P, B, SilentOp) is an implementation of the SPARQL protocol"
>  "an implementation"? I think what's meant here is Invocation(...) makes a request against the named SPARQL protocol implementation.
yes, you are right, I will change it
>  I don't think SilentOp makes sense as an argument to Invocation(). Makes more sense in the defn. of eval(D(G), Service(...))
yes, you are right too, I will keep it in the defn
> "with no default-graph-uri or named-graph-uri"
>  Why aren't these allowable in the service IRI?
Because the idea of SERVICE is to query remote SPARQL endpoints, not 
named graphs.
> "Definition: Strongly bound variable"
>  I think there's missing clauses for BIND and property paths (e.g. ?s :p{0} ?o should result in both ?s and ?o being strongly bound).
>
> "P = SELECT E1 ... En WHERE { P1 } and ?X is strongly bound in P1 and ?X = Ei"
>  Should include the required 'AS ?var' syntax for expressions that aren't variables
>  Should include the option for the select expression to strongly bind the variable: (if "(Ej AS ?X)" is one of the select expressions)
>  This ignores the possibility of ?X being strongly bound in GROUP BY or HAVING clauses
>
> "P = P1 GROUP BY E1 ... En such that either there is an Ei of the form ?X or ?X is strongly bound in P1"
>  Needs to also consider grouping expressions that are aliased ("GROUP BY (Ej AS ?X)")
>
> "P = P1 HAVING ( E1 ) and ?X is strongly bound within P1"
>  This ignores the possibility of ?X being strongly bound in a GROUP BY clause.
>
yes, you are right, I will add all the suggestions to the boundedness 
definition.
> "UNBOUND is not a possible value for ?Xi in BindingValues"
>  I don't know what "not a possible value" means. "?Xi is not unbound in BindingValues"?
it is related to the issue you noticed in the service04.arq test. I will 
fix that.
> Section 4.1
>
> "It is considered a syntax error to use a variable as the first argument of a ServiceGraphPattern if that variable is not bound (at least optionally) before the execution of the SERVICE pattern"
>  How is a query writer supposed to know in what order evaluation takes place? Asserting a syntax error based on evaluation order seems overly confusing.
the boundedness condition allows to check when a variable is going to be 
bounded or not, it implicitly determines the execution order, so it 
would be possible to throw a syntax error. Maybe a syntax error is not 
the best error it could be there, any idea?
> "If a solution does not bind the variable, or binds it to something which cannot resolve to a SPARQL service, that solution is eliminated."
>  The solution is eliminated *unless* the SILENT keyword is used, right?
yes, you are right.
>
>
> thanks,
thanks to you for the detailed comments. I will address them during 
today and tomorrow, and they will be fixed by Thursday or Friday. Sorry 
for such delay.

Carlos
> .greg
>
>

Received on Monday, 18 July 2011 15:13:27 UTC