- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Tue, 18 Sep 2007 03:16:27 -0400
- 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 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&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. 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 07:16:40 UTC