W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2005

Re: solution modifiers & construct/describe

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 27 Jun 2005 19:54:54 +0100
Message-ID: <42C04B7E.7010307@hp.com>
To: kendall@monkeyfist.com
Cc: DAWG Mailing List <public-rdf-dawg@w3.org>

Kendall Clark wrote:
> On Mon, Jun 27, 2005 at 04:57:01PM +0100, Seaborne, Andy wrote:
>>True it's example driven but that can't mean there is an example for every 
>>possible usage pattern.   That would be a whole book.
> I think you can safely assume I understand *that*! The point is that here's
> an instance where the doc is unclear and an example would help clear up the
> confusion. Adding another example *never* implies adding all conceivable
> examples, after all. :>
>>then the definitions use "SM(QS)" to show the application of the modifiers.
>>Err - CONSTRUCt doesn't clearly - that needs to be corrected.
> Yep, precisely.
>>I'd like to make it more permanent (it is currentl broken due to CSS 
>>chnages :-() and then a link in the doc could be made.  An alternatively, 
>>can we provide a static page of the definitons and reference that?
> I'd prefer to see an appendix with all the definitions together *inside* the
> spec. (Actually, I'd prefer to see all the defintions rewritten to use
> relational algebra, but that's an idle preference at this point! :>)
>>Err - that woudl make the defintions long, repetitive (obscuring the new 
>>salient part) and likely inconsistent as changes are made.
> I obviously don't agree, but, as I said, that's an alternative possibility
> to my preference that defintions be gathered into an appendix inside the doc.
>>it is not a partcularly important one for describe/construct as the 
>>returned graph is limited in ways that the requestor can't necessarily 
>>determine (limit/offset and ordering are a poor cursor mechanism). 
> I agree. So why don't we just drop this? Disallow those solution modifiers
> for DESCRIBE & CONSTRUCT query forms. Seems a perfectly reasonable
> restriction.
>>In the 
>>case of construct or describe I think the use is more to do with error 
>>control than slicing graphs.
> I don't find it useful at all, and I'd like to see it just dropped. That
> would solve a lot of these problems. As I recall both the discussions, the
> use cases, and the requirements, these SMs were always about variable
> binding results.
> Kendall

SELECT and CONSTRUCT aren't so very different:

# Get the name and hits of the top 10 blogs:

PREFIX :        <http://host/MyApp#>

PREFIX  foaf:   <http://xmlns.com/foaf/0.1/>
PREFIX  site:   <http://example.org/site#>

CONSTRUCT { [] :result ( ?name ?hits ) }
     []   site:blogHits  ?hits ;
          site:author [ foaf:name ?name ] .

Received on Monday, 27 June 2005 18:55:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:47 UTC