W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

RE: [sub-select] Some examples and discussion

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sat, 14 Mar 2009 18:10:03 +0000
To: Chimezie Ogbuji <ogbujic@ccf.org>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3628D133849@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: Chimezie Ogbuji [mailto:ogbujic@ccf.org]
> Sent: 14 March 2009 00:53
> To: Lee Feigenbaum
> Cc: Seaborne, Andy; SPARQL Working Group
> Subject: Re: [sub-select] Some examples and discussion
> Originally, I was concerned that arbitrarily-nested sub-selects might
> introduce some non-linear recursion that using ASK as FILTER expressions
> does not.  So, the limitations I had in mind were syntactic and ensured the
> recursion in sub-selects are not of the more complex kind.
> However, the scoping effect of group graph patterns used with sub-selects
> seems to ensure that computations within a sub-select are local to the group
> graph pattern with the exception of the solutions returned:
> SELECT ...
> {
>    { SELECT ...
>      {
>        ...
>      }
>    }
> }
> I'm not so sure about whether the proposed assignment syntax provides the
> same (or similar) guarantees.

We do need to watch out for interactions as we consider the set of features we work on as a whole.

The form 
  LET(?x := expression) 
does not give recursion - the expression is valuated there-and-now and can't refer back outside itself or to itself (no names for computation except filter functions).  Like "x = x*2".

Adding SELECTs in expressions as well as sub-selects in patterns does not introduce anything new as far as I can tell; the same effect is achieved by writing as a pattern sub-select just before the expression so the positioning in an expression is merely helpful.

There are no names for an evaluation form so no direct recursion here (there is in custom filter functions by the way).  And we don’t have loops either - good to watch out for clever ways to get the loop effects.


> -- Chimezie
> On 3/12/09 9:21 PM, "Lee Feigenbaum" <lee@thefigtrees.net> wrote:
> > Chimezie Ogbuji wrote:
> >> On 3/12/09 9:14 AM, "Seaborne, Andy" <andy.seaborne@hp.com> wrote:
> >>> As for implementation, putting subs-selects was not hard when I added
> the
> >>> functionality in ARQ and I didn't have an existing DB engine to pull
> >>> existing
> >>> features from.  I don't think it was luck that other designs decisions
> had
> >>> set
> >>> things up, more it was a natural step.  Other opinions may differ.
> >>> What is hard, as had been pointed out, is optimization, but that is not
> to
> >>> be
> >>> specified.
> >>
> >> I don't think I agree that optimization and implementation effort (which
> is
> >> a direct consequence of the complexity introduced by more expressive
> query
> >> forms such as sub-selects) should *not* be a factor.  In fact, it is
> mostly
> >> my concern in this regard that motivates me to suggest that we consider a
> >> spectrum of sub-select features to include.
> >
> > Chime, I was intrigued by your suggestion regarding a limited form of
> > sub-select on the teleconference, but admit that I couldn't immediately
> > see what that would look like. Do you have a concrete proposal for how
> > this might work? (just a sketch would be helpful!)
> >
> > thanks,
> > Lee
> >
> ===================================
> P Please consider the environment before printing this e-mail
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S. News & World Report (2008).
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.

Received on Saturday, 14 March 2009 18:13:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC