Re: newbie question about sparql and 200

OK, let's try a concrete example. Suppose someone has written in SPARQL:

select * from <http://purl.org/obo/obo-all/envo/envo.owl> { ... }

I want to know whether this is correct SPARQL and correct server behavior. I
also want to know what the URI denotes so that I know how to use it properly
in other contexts (such as provenance tracking).

The relevant specs are SPARQL, the httpRange-14 resolution, AWWW, and
HTTP/1.1.

If you dereference this URI, after a redirect or two you get a 200 response
and a representation with content-type application/rdf+xml. httpRange-14
says that this implies that the URI denotes an information resources.

The triples will be selected from an RDF graph, presumably the one that is
serialized in this representation. Now by looking at the spec, it wasn't
clear to me whether the URI in a FROM was to denote a graph, or an
information resource; and from AWWW it is not clear whether the classes of
graphs and information resources can overlap. I know that some people assert
that mathematical objects such as numbers are not IRs, and an RDF graph
seems every bit as mathematical as a number.

So I see four possible interpretations.

1. The URI denotes the RDF graph; an RDF graph is an IR; and the
representation of the graph is its serialization

2. The graph and the IR are different; the thing named in the SPARQL is the
IR; "named graph" is a friendly abuse of language that really means (in the
SPARQL context) "potentially unnamed graph for which there is a named IR
providing serializations of it" and FROM <U> means "from the graph whose
serializations are representations of the IR named by U".

3. The SPARQL is in error because the FROM has to name a graph and the URI
doesn't name a graph

4. The server is in error because the URI is supposed to name a graph and a
200 was delivered, and graphs are not IRs (200-able)

I vote for number 2 based on what I've heard you and Tim say (numbers are
not IRs). 3 and 4 would break nearly all deployed SPARQL client/server
configurations.

Jonathan

On Fri, Aug 15, 2008 at 11:30 AM, Dan Connolly <connolly@w3.org> wrote:

> On Thu, 2008-08-14 at 22:08 -0400, Alan Ruttenberg wrote:
> > [trimming the leading section to focus on your response]
> >
> > On Aug 14, 2008, at 6:47 PM, Dan Connolly wrote:
> > >
> > > Well, yes, it's fine for different representations to be
> > > returned, but combined with the "from URI identifies
> > > the graph", it leads to conclusions. Consider:
> > >
> > >  select ?P from <http://nytimes.example/stocks> {
> > >      _:someStock nyse:sym "XOM"; nyse:price ?P }
> > >
> > > Two parties run the query. When p1 sends
> > > the query to a SPARQL endpoint, which turns
> > > around a does a GET where the response is
> > >
> > >   200
> > >   Date: ... 14:00
> > >   Content-Type: text/turtle
> > >
> > >   <#xom> nyse:sym "XOM"; nyse:price 10.
> > >
> > > If the SPARQL spec said that the from URI identifies the
> > > graph represented in the response, we would have
> > >   <http://nytimes.example/stocks>
> > >    owl:sameAs
> > >   { <#xom> nyse:sym "XOM"; nyse:price 10. }.
> >
> > Whoa. You've just jumped from saying that the response to the query
> > against the graph, when parsed, gives you the graph itself.
>
> ???
>
> I never mentioned the response to the SPARQL query.
>
> The from URI is (typically) used to get data to query against.
> That's all I'm talking about.
>
> I substituted <http://nytimes.example/stocks> for
> <http://example.com/graph1> to make the scenario a bit
> more concrete, but otherwise, I'm just exploring
> the question that was originally asked.
>
> Are you familiar with whatever prompted Jonathan to
> ask the question? I'd sure like to know more about
> the context of the question.
>
> >  Even if
> > you said "select * from <http://nytimes.example/stocks>  where {?s ?
> > p ?o}" why would you expect this to be the case?
> >
> > -Alan
> >
> > [and trimming what followed]
> > >
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>
>