Re: tests and inference?

Kendall Clark wrote:
> On Thu, Dec 16, 2004 at 12:59:06PM +0000, Seaborne, Andy wrote:
> 
> 
>>Like RDF assertions about any document - we (DAWG) don't need to provide a 
>>mechanism to find, publish, change, sign, ... such information as it can be 
>>a regular RDF graph somewhere.
> 
> 
> In case the record isn't clear yet, I have serious, principled
> disagreements with this position:
> 
> 1. There's a real technical need: discovering service descriptions is
>    a real, tractable problem; punting on it requires more
>    human-to-human communication, increasing costs, deployment time,
>    and decreasing off the shelf interop.
> 
> 2. There are solutions that will work now and provide value: having
>    some standard conventions about how clients ask servers for the URI
>    of the service description is not a difficult thing to standardize
>    -- here I'm not talking about what RDF vocabulary *is* the SPARQL
>    service description, merely putting into the protocol some simple
>    mechanism that allows a responder to say to a requester "the
>    service description URI is foo".
> 
>    (This could be as simple as "OPTIONS *" in the HTTP
>    binding. Despite avowals to the contrary, I think the plain meaning
>    of OPTIONS in HTTP 1.1 is consistent with this usage.)
> 
>    Since we're not at all reluctant about hardcoding URIs -- thus
>    dictating to people the shape of their URIspace, violating a core
>    Webarch principle (IMO) -- why not dictate a URI that means "give
>    me back any machine readable description of this SPARQL service"?
> 
>    GET /qps
> 
>    or  
> 
>    GET /qps?graph=tag:w3.org,2004-12-16:/sparql-p/abstract/service-description
> 
>    This would seem to be upwardly compatible with reasonable, more
>    involved solutions to come later. Sparql service processors can do
>    redirects on that URL indefinitely, for example.

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.

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.

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.

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).

	Andy

> 
> 3. Partial solutions can be very useful: managing service description
>    evolution (Andy's "change") and authentication (his "sign") are
>    harder problems, but I don't think we have to solve *all* of them
>    to do something simple.
> 
> Kendall Clark
>

Received on Thursday, 16 December 2004 16:23:25 UTC