- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 03 Jan 2006 12:10:09 +0000
- To: Kendall Clark <kendall@monkeyfist.com>
- CC: dawg mailing list <public-rdf-dawg@w3.org>
Kendall Clark wrote: > Folks, > > Based on some protocol feedback from Graham Klyne, and some off-list > discussion with Andy, I want to raise an issue for WG consideration. > I think the issue should be raised, added to the issues list, and > then postponed. > > In short, should or shouldn't we have a mechanism for issuing > warnings from a SPARQL service to consumers of that service? > Generalizing a bit, should or shouldn't we have a mechanism whereby a > service issues an annotation of a particular protocol operation? > > These bits are *not* faults in the WSDL sense (i.e., messages that > replace the expected Out Message of a WSDL operation), that is, they > may be debugging messages for developers or annotations of unexpected > results, etc. Andy gives the following examples: > > - "your query took 45ms to execute" > - "that's a strange choice for prefix rdf:" > - "I got a 301 trying to read that URI you FROM'ed" > > I'll add: > > - "the explanation of that query results, which included inference, > is..." > - "the generated proof for that policy is..." > > If we should, how should those warnings be communicated? The > possibilities seem to include: > > 1. putting them in-band, i.e., in the results format > 2. putting them out-of-band but linking to them in the results > format; that is, conceptualizing these annotations of a protocol > request as separate web resources and providing a link to them in the > results format > 3. putting them into the WSDL Out Message itself. (Which would mean > different things for different bindings. In HTTP it might mean an > HTTP header in the response or a multipart response.) > > I don't believe we can use WSDL faults for this information, not only > because faults replace messages (for the fault propagation rule we're > using), but also because these really *aren't* faults. They're more > like hints, warnings, notes, etc. Andy's word, 'annotations', seems a > good umbrella term. > > FWIW, I prefer a design like (2) above; the results format gets a new > element or attribute, (say, "protocol-operation-annotation" for > maximal legibility), which contains a URL. When dereferenced, that > URL returns a representation of the service's annotations of a > particular protocol operation request and response. That > representation might be human or machine readable, which could be > negotiated for when the URL is deref'd, and it might include none, > some, or all of the results, plus whatever other annotating > information the service wants to communicate. Can we use the current <link> mechanism here? It points to some metadata for the results. I don't see a need for another element as such. Your example below shows that the boundary between warning and "additional information" is not clear-cut. > > (One reason not to put them in-band, either in the results format or > in the WSDL Out Message, is size and complexity considerations. > Suppose a service does optional inference explanation or proof > checking. If you want to see the full explanation of some inferences, > or the full debugging trace of an operation, you pass a flag and the > service will annotate the results accordingly. But in some > formalisms, explanations and proofs can be very large. Large enough > and conceptually distinct enough that it makes sense, at least to me, > to consider these web resources in their own right, give them a URL, > and deref them when or if the client decides to.) > > I also prefer to raise this issue now, perhaps discuss it, then > postpone it till later. > > Cheers, > Kendall > There remains the matter of warning for RDF/XML results over plain HTTP. I don't see where addition information can be inserted. Postponing would be acceptable. Andy
Received on Tuesday, 3 January 2006 12:11:15 UTC