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

RE: DESCRIBE with GRAPH

From: Geoff Chappell <gchappell@intellidimension.com>
Date: Fri, 25 May 2007 13:43:58 -0400
To: <andy.seaborne@hp.com>
Cc: "'Richard Newman'" <r.newman@reading.ac.uk>, <public-rdf-dawg-comments@w3.org>
Message-Id: <20070525174417.62A5FA0185@gorp.greenriver.org>

Thanks, Andy. Fits my impressions, but wanted to make sure I wasn't missing
anything.

-Geoff

> -----Original Message-----
> From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
> Sent: Tuesday, May 22, 2007 6:32 AM
> To: Geoff Chappell
> Cc: 'Richard Newman'; public-rdf-dawg-comments@w3.org
> Subject: Re: DESCRIBE with GRAPH
> 
> 
> 
> Geoff Chappell wrote:
> >
> >> -----Original Message-----
> >> From: Richard Newman [mailto:r.newman@reading.ac.uk]
> >> Sent: Sunday, May 20, 2007 10:08 PM
> >> To: Geoff Chappell
> >> Cc: public-rdf-dawg-comments@w3.org
> >> Subject: Re: DESCRIBE with GRAPH
> >>
> >>> I realized that DESCRIBE is somewhat loosely defined, but wondering
> >>> what
> >>> other implementations have done in this situation. Any guidance
> >>> appreciated....
> >> As an implementer: I would expect the DESCRIBE to run against the
> >> dataset specified by the FROM/FROM NAMED, not just the contributing
> >> graphs, and certainly not the whole store. As to what the
> >> implementation should do with the named/default dichotomy... well,
> >> that'll be implementation-defined.
> >
> > Thanks for the feedback.
> >
> > Here's my use case:
> >
> > 	http://www.semanticwebsearch.com/query/sparql.rsp
> >
> > In this case, I'd expect no federation, but would want descriptions to
> be
> > graph-bound. OTOH, I can also see cases where I'd want it to behave as
> you
> > suggest.
> >
> > DESCRIBE has no way to distinguish these cases since it uses up all of
> the
> > available language features to specify what subjects to describe, but
> has no
> > way to then say how to generate the descriptions (or where to pull them
> > from). So perhaps we'll just have context specific behavior until it
> gets
> > some more definition? (BTW, even with its shortcomings, I think we're
> better
> > off with it, then without it).
> 
> Agreed.
> 
> One at the moment is to use the protocol request and add extra parameters
> -
> that means the request has additional information for the query even
> though
> it's not in the SPARQL query string itself.  For example, some systems
> allow
> adding "output=" to get JSON in a compatible way with AJAX, or including
> in
> the request that an XSLT stylesheet be included as either a server-side
> process or a stylesheet inclusion.
> 
> 	Andy
> 
> >
> > -Geoff
> >
> >
> 
> --
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
Received on Friday, 25 May 2007 17:44:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:51 GMT