Re: tests and inference?

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.

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 14:32:21 UTC