- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 25 Mar 2009 22:02:05 +0000
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
On 25 Mar 2009, at 17:14, Ivan Mikhailov wrote: > Hello Steve and Andy, > >> * How are the processors supposed to determine the type of the >> arguments? eg is x=1 the integer "1"^^xsd:integer, the xsd:string/ >> plain literal "1", or the local URI <1>, and so on. ...&x=%221%22%5E >> %5E >> %3Chttp%3A//www.w3.org/2001/XMLSchema%23integer%3E seems somewhat >> clumsy. > > We use SPARQL syntax, so &x=1 and &x="1" and &x=<1> differ. That sounds OK, but I don't think there's consensus on that because I think I've seen bare terms in other examples. >> As a general note, I personally don't find the "SQL does it, so >> should >> we" viewpoint to be very persuasive. SPARQL is not SQL, and many >> things in SQL are questionable. I think we should be looking to learn >> from their mistakes, as well as the things they did well. > > Concorde is similar to Tu-144 and Buran is similar to Space Shuttle > that is in turn similar to Bor not due to "commies does it, so should > we". Same purpose and same atmosphere, nothing but. Still, it may be > reasonable to look around, what else is flying in the same > atmosphere :) My point was that some things standardised by SQL are, with the benefit of hindsight, mistakes. Lets be sure that we don't blindly copy them. >> If we do spec this feature, I'd like to see both mandatory and >> optional parameters. Optional parameters can done using the >> existing named variables - the advantage of optional is that when >> results from one query are being used to drive another, optionals >> do occur. The added checking of mandatory parameters, with >> variables with a distinguished name (?:name was suggested) is, I >> feel, sufficiently valuable to justify the additional specing. >> This is not a backward compatible feature. How much do we want to >> smooth the transition for SPARQL/2010 [*] clients querying SPARQL/ >> 2008 servers? > > We're intending to introduce tons of features that will cause troubles > for SPARQL/2008. Parameters is at least something that will cause > unambiguous errors. My organisation is keen to avoid introducing anything that will cause trouble. - Steve -- Steve Harris Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK +44(0)20 8973 2465 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Wednesday, 25 March 2009 22:02:41 UTC