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