Re: Late comment on DESCRIBE

On Mar 27, 2006, at 05:58, ext Graham Klyne wrote:

> This comment is late because it occurred to me only very recently  
> in offline
> discussion.
> regarding
> 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- 
> ]]
> --
> In the previous last call, I objected to the inclusion of  
> 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 think this is a great idea. It allows for queries to be more
specific about the form of description needed rather than it
being left implicit in the query and buried in the application

E.g. to request a CBD, one would use

    DESCRIBE ( <> ) <target-list>

I like it.



> 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:

Received on Monday, 27 March 2006 13:49:58 UTC