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