Re: SPARQL Query Results XML Format

Alan Ruttenberg wrote:
> 
> Sorry I haven't been following DAWG closely and noted something when it 
> came to my attention.
> 
> It's been my experience that this is a useful thing to do. Space for 
> other information such as for debugging would also be useful, such as 
> processing times, system the query was processed, date the query was 
> executed on, endpoint against which it was run, vendor specific 
> settings, etc.
> 
> I see that there is a link possibility for additional metadata, however 
> a) Such metadata requires state to be kept on the  server, and is 
> unlikely to be saved in the long run. b) There is no given structure to 
> that metadata, so there can be no expectations across implementations.
> 
> Here is a specific proposal based on  doing queries against Ingenuity's 
> knowledge base, very similar in spirit to SPARQL.
> 
> <head>
>   <query>SPARQL select ... </where>
>   <endpoint>http://ashby.csail.mit.edu/sparql/</endpoint>
>   <queryparameters>foo=bar&amp;maxresults=10</queryparameters>
>   <when>time when the query was executed</when>
>   <meta> what the "link" would retrieve, possibly enclosed as PC data if 
> there are validation issues</meta>
>   ...
> 
> Proposal is that all would be optional, so as not to scare people away.

Hi Alan (and Danny and Alex),

The DAWG discussed this comment on our teleconference this morning and 
there was no support among the working group members to pursue this at 
this point in our schedule. The schedule cost to the group in terms of 
design (we are unfamiliar with existing consensus on designs for this in 
current SPARQL implementations) and process was deemed too expensive.

Lee

> 
> It was not clear to me whether additional xml elements other than the 
> ones currently specified can be specified in the body of a sparql 
> result. I would
> 
> At a minimum, allowing the metadata to be embedded in the XML would be a 
> good idea. If the current spec precludes additional elements in the 
> result XML, then relaxing that would be the first step.  Next in 
> priority would be to standardize the element for the query. Then 
> standardize some attributes like dates and times. Then allow an element 
> with vendor specific information.
> 
> Lee has pointed out 
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jun/0028.html 
> which spurred the addition of the link element.
> The problem with this is that, as I point out, it is unlikely that 
> implementations would choose to provide long lived metadata which would 
> accumulate on a server. This information is such that it is known at the 
> time of query and would most effectively be communicated in the body of 
> the query results.
> 
> 
> -Alan
> 
> 
> 
>

Received on Tuesday, 18 September 2007 22:00:15 UTC