Re: tests and inference?

On Thu, Dec 16, 2004 at 04:23:06PM +0000, Seaborne, Andy wrote:

> We seem to be in some agreement here if I understand the example correctly. 
> The client is accessing a service description graph named "tag:.." - that 
> could even be a http URL so it is generally accessible.  I'm not clear if 
> it is the same URI at every service or different for each service.  The 
> former seems odd on the web.

I want "universal" clients that either know how to (1) ask any Sparql
server for it's service description, whether that means giving one
service description identifier to any Sparql server or hardcoding a
way to form the URI for the service description; (2) or implement a
protocol convention for the client to request (say, OPTIONS *) from a
Sparql server the identifier of *its* service description.

The problem with GET /query-processor-service is that it doesn't work
for graph-centric implementations, that is, ones that don't expose a
query processor via a URI. (But this and the same problem below with
OPTIONS is a good reason to *always* give the query processor service
a URI.)

> For the latter, there is nothing in the SPARQL spec that needs to define 
> the URI of the graph or its form.  (An "http:" would be better to make it 
> on the web). Services just provide a graphto eb queried to get information 
> about the service.

How do clients discover, for any arbitrary Sparql server, which
special graph they should query to get information about the service?
I presume they have to discover this since you don't want to specify a
token or URI or identifier for this special graph, right?

> It's the "dictate a URI" part can't quite see.  I'd have thought the URI 
> for the graph will different for each service (the latter case of the two 
> above) - returning that vai OPTIONs - or an HTTP header (use HTTP HEAD to 
> get it) would work.  Sort of like rdf:seeAlso for HTTP requests.

The problem with OPTIONS (though I think it's not *too* bad) is that
it makes perfect sense for a service-centric implementation style:

OPTIONS http://monkeyfist.com/sparql-processor.py

returns either (1) the service description graph, or (2) a URI that
identifies the service description graph.

It makes a lot less sense in graph-centric implementations, which may
not expose a query processor URI at all. But I can look past this
wart.

> There is probably way to use an existing HTTP header as well. Or put it in 
> the graph being queried (works better for the query over multiple graphs 
> case).

I prefer the OPTIONS approach. I'm gonna think about this some more
and consider drafting some language to add to the protocol spec.

Kendall Clark

Received on Thursday, 16 December 2004 18:05:34 UTC