W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2012

Re: FROM and FROM NAMED: To fetch or not to fetch?

From: David Booth <david@dbooth.org>
Date: Fri, 22 Jun 2012 13:43:40 -0400
To: Gregory Williams <greg@evilfunhouse.com>
Cc: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
Message-ID: <1340387020.6980.19846.camel@dbooth-laptop>
Hi Greg,

On Fri, 2012-06-22 at 13:12 -0400, Gregory Williams wrote:
> David,
> I suspect most of this will be addressed in a formal response, but I
> wanted to briefly comment on this:
> On Jun 22, 2012, at 12:24 PM, David Booth wrote:
> > - The LOAD operation already provides a means of fetching, so (now that
> > we have SPARQL Update) a second means of loading by use of FROM or FROM
> > NAMED is redundant.  
> I don't think LOAD makes a dereferencing FROM redundant at all. For
> example, an implementation can do dereferencing to provide a
> general-purpose query service (e.g. sparql.org) without providing (or
> implementing) Update or any sort of persistent graph store. Even if
> such a system *did* implement Update and have a persistent graph
> store, though, a general purpose query service would be very
> cumbersome for users as it would require two separate protocol
> requests: one to load the data, and one to query the data (and assumes
> nobody has dropped, cleared, or updated your data in-between the load
> and the query).

Yes, I guess that is a different use case, for which fetching behavior
is quite handy.  But I still think the issue comes down to the fact that
fetching is very different from not fetching, and the two behaviors
should not share the same ambiguous syntactic directive.  

For example, I could imagine that use case being handled by a FETCH
keyword rather than a FROM keyword.

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Friday, 22 June 2012 17:44:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:12 UTC