W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > September 2007

SPARQL Query Results XML Format

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Tue, 18 Sep 2007 03:16:27 -0400
Message-Id: <FD81C906-04F3-4085-BCF5-FA0D9E960D3D@gmail.com>
To: public-rdf-dawg-comments@w3.org

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  

Here is a specific proposal based on  doing queries against  
Ingenuity's knowledge base, very similar in spirit to SPARQL.

   <query>SPARQL select ... </where>
   <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.

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.

Received on Tuesday, 18 September 2007 07:16:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:09 UTC