Kendall Clark wrote:
> On Sun, Mar 06, 2005 at 09:57:28AM +0000, Seaborne, Andy wrote:
>>Approach 1: "CONSTRUCT *" is illegal if the query uses GRAPH.  The
>>application writer has to be a bit more explicit and provide a template
>>that more accurately describes what they want.
>>Approach 2: "CONSTRUCT" returns a dataset.  Need to extend CONSTRUCT
>>templates to include GRAPH.
>>Approach 3: Drop "CONSTRUCT *" all together.
>>My preference is 3 > 1 > 2.
> If we do (3), I want to reintroduce the idea of getGraph in at least
> the abstract WSDL interface (or in a separate interface), since my
> willingness to drop getGraph was tied to the CONSTRUCT * alternative.

Good point.  "CONSTRUCT *" is, and always has been, only a shorthand - and 
that is the diffiuclty in extending it to query patterns involving GRAPH.

"CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }" does the trick but isn't as pretty.

It's as is GetGraph operates on accessing the elements of a dataset.

The more complicated

CONSTRUCT { ?s ?p ?o } WHERE
   GRAPH ?g { ?s ?p ?o }
   { ?g dc:publisher <> }
   { ?g dc:date ?date }
   FILTER app:myDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime

shows a "GetGraph"-like action but with conditions on the graph which are 
not based on name.

> I don't recall what our WSDL sketch said about getGraph, and I can't
> find the WSDL sketch in our archives...
> (And setting aside the getGraph dependency, I agree about dropping
> Kendall


Received on Sunday, 6 March 2005 16:27:09 UTC