W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Re: fed review

From: Carlos Buil Aranda <cbuil@fi.upm.es>
Date: Tue, 19 Jul 2011 22:53:55 -0400
Message-ID: <CABdcz9H2x0rqTq7o5tHdDov0=N7JPvKMnzBYQoiouHYLh1sGsA@mail.gmail.com>
To: Gregory Williams <greg@evilfunhouse.com>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
any more opinions on that?



2011/7/19 Gregory Williams <greg@evilfunhouse.com>

> On Jul 19, 2011, at 5:02 PM, Carlos Buil Aranda wrote:
> > just summarizing a bit, the main concern is the use of variables in
> SERVICE. The problem relies in the specification of the semantics and the
> boundedness condition which suggests an order for executing the query. The
> problem is first, the way of defining the execution of SERVICE VAR, which
> using the current join semantics is wrong because it is not possible to
> evaluate Join(G, Service(VAR, G, Transform(P), SilentOp)) because VAR still
> hasn't a value. Following this, the boundedness condition, which has to be
> completed for all the SPARQL 1.1 operators. Am I right?
> Thanks Carlos. Yes, I think this is a good summary of the biggest issues.
> > So, the possible solutions are:
> >  - For the SERVICE VAR semantics
> >    - add a new operation that could allow the evaluation (operation which
> wouldn't be bottom-up)
> >    - define its whole semantics in a new way
> >  - For the boundedness restriction
> >   - specify all cases: it may take a bit long
> >   - remove it? I do not think this is a good idea, how do we specify then
> that a variable is bound (which is needed for the evaluation semantics of
> It might be needed for the evaluation semantics, but I don't think the
> current text connects the two. There is no mention of strongly bounded
> variables or service safeness in the "Definition: Evaluation of a Service
> Pattern" section.
> thanks,
> .greg
Received on Wednesday, 20 July 2011 02:54:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:04 UTC