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 <http://www.w3.org/> } { ?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 > "CONSTRUCT *".) > > Kendall AndyReceived on Sunday, 6 March 2005 16:27:09 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 October 2009 14:42:01 GMT