W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: how to subsume or handle warnings?

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 03 Jan 2006 12:10:09 +0000
Message-ID: <43BA69A1.2030608@hp.com>
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 

Received on Tuesday, 3 January 2006 12:11:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC