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

Re: Update comment

From: Paul Gearon <pgearon@revelytix.com>
Date: Tue, 29 Mar 2011 11:15:23 -0400
Message-ID: <AANLkTinyAL7q_Yn4Rtc24DRr=nuHKXrQjUXCLxnM1YCM@mail.gmail.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Comments inline.

On Wed, Mar 23, 2011 at 7:30 PM, Lee Feigenbaum <lee@thefigtrees.net> wrote:
> On 3/23/2011 6:14 PM, Andy Seaborne wrote:
>> On 23/03/11 21:53, Lee Feigenbaum wrote:
>>> The SPARQL query spec only specifies an indirect relationship between
>>> graph name and contents for FROM and FROM NAMED, right?. USING should
>>> be the same thing -- I don't think I understand the problem?
>>> Lee
>> It's not the indirect relationship involved FROM NAMED (query sec
>> 13.2.2). Let's just talk about FROM.
> OK. I still think there's either a misunderstanding somewhere or just a
> different worldview, because I still have trouble coming to the same
> conclusion you are coming to.
> My understanding is that the SPARQL query spec (particularly
> http://www.w3.org/TR/rdf-sparql-query/#unnamedGraph) is silent about the
> proper way to get at the contents of the graph specified in a FROM clause.
> The text says:
> "the graphs obtained from representations of the resources identified by the
> given IRIs"
> I've always assumed that this is purposefully underspecified, and that it is
> implementation-defined as to how a SPARQL processor decides what graph is
> meant by g in a "FROM g" clause. (This is why, for instance, it's fine in
> some systems to do "FROM <tag:foo>".)
>> The problem is that FROM typically cause a graph to be read form the web
>> (yes - not in Anzo or Mulgara, but that's unusual).
> I don't really think it matters what is usual or unusual, just that
> according to the spec it's implementation-defined as to where the graph
> comes from.
>> The update spec says USING is identical to FROM (it uses the word
>> "identical").
> Right -- as in, it's identical as far as the spec concerned, which means it
> too is implementation-defined. The spec doesn't say (nor would it really
> have license to say) that a processor must use the same algorithm for
> figuring out the triples in g via USING as it does via FROM, does it?

I think you're right here, though it wasn't my intent. In this case I
was trying to aim for USING to simply be a syntactic replacement for
the word FROM. Therefore, whatever the specific store does for FROM is
also what I would expect from USING. However, since you point out that
the definition is loose, then I suppose that means that graphs to use
in the WHERE clause can vary by context (by "context" I mean queries
vs. update operations).

>> So a reasonable expectation of an engine that reads from the web is that
>> USING does as well. We added USING so the graph can be picked from the
>> graph store so its not identical in such a system.
> I thought we just added USING to have a way to assemble a specific RDF
> dataset. I assumed that some stores that pick graphs off the Web would
> continue to do so for USING/USING NAMED. Why wouldn't they?

My thought as well.

The point here was to be able to construct a dataset in exactly the
same way that a CONSTRUCT query does. It would have been ideal if we
could continue to use FROM, but the DELETE/FROM syntax was just too
confusing for users to allow it.

>> And the text goes onto indirectly imply this as well by talking about
>> WITH which does mean a graph in the store.
>> Earlier:
>> "The WITH uri defines the graph"...
>> would be better as
>> "The WITH uri defines the graph in the graph store "...
> Agree.
> All that said, I'm not exactly sure where my our understandings are
> diverging, but do you have suggested alternate text that would address your
> concerns?

I'm happy to make the change to WITH. I just don't see that there are
problems elsewhere.

Received on Tuesday, 29 March 2011 15:15:57 UTC

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