Re: solution modifiers & construct/describe

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 ) }
WHERE
{
     []   site:blogHits  ?hits ;
          site:author [ foaf:name ?name ] .
   }
ORDER BY DESC(?hits)
LIMIT 10
-------------------

	Andy

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