- From: Graham Klyne <GK@ninebynine.org>
- Date: Mon, 27 Mar 2006 12:58:46 +0100
- To: public-rdf-dawg-comments@w3.org
This comment is late because it occurred to me only very recently in offline discussion. regarding http://www.w3.org/2001/sw/DataAccess/issues.html#DESCRIBE and: [[ * The working group adopted DESCRIBE without reaching consensus. The objection was that the expectations around DESCRIBE are very different from CONSTRUCT and SELECT, and hence it should be specified in a separate query language. If you have input to this aspect of the SPARQL that the working group has not yet considered, please send a comment to public-rdf-dawg-comments@w3.org. ]] -- http://www.w3.org/TR/2006/WD-rdf-sparql-query-20060220/ In the previous last call, I objected to the inclusion of DESCRIBE. That objection has not been addressed, but I didn't respond again because I didn't feel I had anything new to add to what I said before. But now I have a simple proposal to modify DESCRIBE that would overcome my objection to it. Essentially, the approach is to use DESCRIBE as an extension hook rather than as a catch-all for stuff that couldn't be agreed at this time. I propose that the form of DESCRIBE be changed from: DESCRIBE <target-list> to DESCRIBE(<result-type>) <target-list> where <result-type> is a URI that identifies a particular form or vocabulary of RDF description of the target URIs, possibly (but not necessarily) by reference to some schema or ontology or query. Developers can then deploy private-use DESCRIBE results (as now) by using a private URI, but there remains scope for developing interoperable DESCRIBE responses by associating them with a published URI. I believe this would clear the path for future standardization efforts for interoperable DESCRIBE responses, if these prove to be needed, and make it quite clear that near-term implementations cannot be regarded as generally interoperable. It would also create some onus on developers to create a description of what their DESCRIBE implementations actually do return (to be lodged at the URI, of course). #g -- PS: There is a possible development of this idea, which I am *not* proposing here, but which I mention to place it on the record. There is some concern about more powerful query constructs (e.g. disjunction, recursive closure) that cannot be addressed with SPARQL as it stands. The form of DESCRIBE suggested above might provide access to future developments in this area; if DESCRIBE could be used in conjunction with other result type keywords (e.g. SELECT) then alternative result formats, such as variable bindings, might be derived from the RDF graph constructed by DESCRIBE rather than just the original input graph. Clearly, this is currently half-baked - it's just a thought. -- Graham Klyne For email: http://www.ninebynine.org/#Contact
Received on Monday, 27 March 2006 12:00:08 UTC