Data Access Working Group

Convene, take roll, review records and agenda

ACTION: EricP to send [OK?] message to Bjoern [DONE] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action01]

ACTION: EricP to respond to "ORDER with IRIs" comment [DONE] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action02]

ACTION: DaveB to to propose source test to approve [CONTINUED] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action03]

ACTION: DanC to follow up re optional test based on op:dateTime triple [CONTINUED] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action04]

ACTION: DanC to notify www-rdf-comments about difference between RDF URI refs and IRIs, e.g. spaces [CONTINUED] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action05]

toward Note on using SPARQL with WSDL 1.1

ACTION: Lee to elaborate on how to use this WSDL 1.1 stuff with tools [DONE] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action06]

ACTION: KC, EricP to review WSDL 1.1 sparql protocol publication candidate, once a candidate pointer is mailed to the WG [DONE] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action07]

DanC: SOTD is non-trivial for the Protocol WSDL 1.1 Note

ACTION: DanC to publish WSDL 1.1 sparql protocol note, contingent on thumbs-up from KC, EricP, Lee/Elias [CONTINUED] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action08]

protocol testing update

ACTION: Jeen try to reproduces EliasT's protocol testing results [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action09]

<EliasT> SPARQL Protocol Test Suite Update

<AndyS> The page at DataAccess/proto-tests/ dated 01-Sep-2005 22:08 does not mention protocol

<EliasT> Makefile has been committed

SPARQL Protocol and WSDL

kendall: the WSDL WG resolution favors the current SPARQL WSDL plan

DanC: does that mean our WSDL is ready?

DanC: DanC: I've seen responses to our (DAWG's) last call comments on WSDL 2.0 to the effect that "yes, we'll make changes to accomodate your needs" and mail back from kendall saying "ok, we're happy"

kendall: not quite

Bijan: the WSD WG is working on the ability to POST a URL-encoded query to a bare UIR

[discussion of RE: limitations of {http output serialization} thread]

ACTION: KendallC to propose revised WSDL descripton of SPARQL protocol w.r.t. [missed] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action10]

ACTION: DanC to notifty DAWG of WSDL response to our WSDL comments [PENDING] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action11]

ACTION: DanC to ask WSDL WG to review WSDL 2 SPARQL protocol stuff, once both are available [DONE] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action11]

ACTION: DanC to ask WSDL WG to review WSDL 1.1 protocol stuff, once it's are available [PENDING] [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action12]

<AndyS> I noted <fault name="QueryRequestRefused" whttp:code="500"/> but 500 is server internal error. http://www.w3.org/Protocols/HTTP/HTRESP.html

<kendall> What's the point, Andy?

<kendall> 500 is the most general "request unprocessed because of server condition" code... Is there another you'd suggest?

<AndyS> 500 is not the right code (server error) 4xx are client errors

<kendall> but refusing to process a query isn't a client error

<SteveH> AndyS, Kendall and I discussed this on the list previously...

<kendall> yep

<AndyS> I still think it is wrong. See earlier ref.

<kendall> Yes, I see that you think it's wrong. I still don't understand why you think it's wrong and what you would suggest using otherwise.

<kendall> Just read the spec:

<kendall> 10.5 Server Error 5xx

<kendall> Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request.

<AndyS> I have just said why. Refused !=> server internal error. See 400 : The request had bad syntax or was inherently impossible to be satisfied.

<kendall> That's not what the spec says, Andy.

<kendall> 500 says, explicitly, that the server is "incapable of performing hte request"

<kendall> 400 only says "by the server due to malformed syntax", which is not what QueryRequestRefused semantics are.

<kendall> 500 says "The server encountered an unexpected condition which prevented it from fulfilling the request.

<kendall> "

<EliasT> 400 The request had bad syntax or was inherently impossible to be satisfied.

<kendall> Well, that's not what my copy of HTTP 1.1 on the W3C site says, interestingly enough. :>

<kendall> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

<EliasT> ahh different documents.

<LeeF> Let's split the difference and make it 450. ;-)

<kendall> heh

<kendall> i mean, none of them is precisely right, clearly.

<EliasT> Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request.

<kendall> yep, as I quoted. :>

<EliasT> is the service incapable or just not willing?

<EliasT> :-)

<kendall> Well, yes, of course. There's a bit of semantic stretch in *any* of them. ;>

<kendall> 500 are not all server *errors* anyway!

<kendall> not available now, or not implemented are not errors

<EliasT> I guess it's more folk wisdom to not use 500 except for crashes.

<kendall> so i'd be fine with 501, then

<kendall> but i'm totally unconvinced that it should be a 4xx

<kendall> but i'm also unconvinced by mere appeals to folk wisdom

<EliasT> right. agree. nothing like a good spec to follow.

<AndyS> Folk wisdom matters here because app servers do it automatically :-)

<kendall> 4xx is the wrong status code group

<kendall> if someone wants to suggest 501 over 500, I think that's reasonable

<kendall> I don't care that much what app servers do. Which ones? Not the one I use.

<AndyS> "406 Not Acceptable"?

<kendall> Nope, 406 is wrong too.

<kendall> 4xx is wrong: " The 4xx class of status code is intended for cases in which the client seems to have erred." There's no implication to that effect in QueryRequestRefused; in fact, I *think* it says otherwise explicitly.

# issues#rdfSemantics

see DanC's rdfSemantics issue summary

<DaveB> checking the dawg charter it seems to hint that entailment could be in the service description or protocol

PatH: we need to keep bNode rigidity orthogonal to entailment selection

Bijan: [nods]

DanC: editor comments?

AndyS: I think redundancy optional will have hidden traps

Dave: I think the results format should reflect the entailment used, in the "parameterized entailment" case

<bijan> +1 to dave's comment

<AndyS> We have the <link> as well for an open ended set of info

<bijan> I'm fine exploiting <link> for that

<DaveB> I'd probably suggest a separate <entailment> (handwave) term

Bob _:a

Bob _:b

EricP: I'd like to achieve a sort of minimalism where Bob/_:a and Bob/_:b would be reduced to Bob/_:a

<bijan> You can keep the results set with told redundancy, then minimize that result set to check for non-rigid simple entailment

<AndyS> Query: { ?Bob foaf:name "foo" }

<DanC> (I think we've gotten off track; we're not hearing the editors think about the spec impact of the 3 proposals; we're cooking up other proposals.)

<DanC> (but since "redundancy optional" is pretty fuzzy...)

<patH> Foaf is built with an implicit unique name assumption (quite common). So with Andy's query, distint bnode replies FOAF-entail two people.

DanC: tests already follow redundancy optional. will require an identifier for redundant rows to test LC design

<patH> Even though that isnt a strictly correct RDF entailment, its not RDF-wrong. And a FOAF-savy querier to a FOAF-savvy source can communicarte usefully when 'redundancy' isnt removed.

<bijan> patH, but it seems like that should get a distinct uri indicating those assumptions

<bijan> I.e., it should exploit this extensibility point

[DanC and AndyS discuss { _:x bindsTo "X" ; bindsTo _:X } == { _:x bindsTo "X" } ?]

<DanC> . http://www.w3.org/2001/sw/DataAccess/issues#rdfSemantics

<patH> Well, sure, Bijan, but we have to be careful not to build in redundancy-removal so as to rule this opiut. Also there is no 'name' for this.

<patH> opiut/out

<bijan> I agree about the building in redundacy-removal so as to preclude important options, natch :)

<bijan> And I agree that there is currently no name for it

<bijan> but I suggest that providing that name isn't our job, but hte foaf community's

<patH> Bijan, I think all I am saying is that the bnode-redundancy should be ortthogonal to entailment, whcih was laredy made.

<bijan> We support them by supporting and extensiviblity point

<bijan> yeah

<bijan> Which is cool

<bijan> I think that woudl be a great example to discuss in the spec

<bijan> To encourage peopel in that direction

<bijan> If we had a primer :)

<kendall> Do not stare at Happy Fun Ball.

<DanC> consider a 4th column... query parameterized

<DanC> DaveB: it seems similar to limit

<Zakim> DanC, you wanted to note "parameterized entialment" seems to interact with the bounds of the charter

<patH> Dan, I thikn point is not so much for us to do this, as to not put out a design that rules it out as a future.

[POLL] (a) LC design / (b) redundancy optional / (c) parameterized entailment / (d) query parameter

<patH> (a), (c) as a second choice.

<DanC> pat, I'm trying to actually address this issue. I want to talk about designs that people are interested to actively support: write text, write code, teach people to use, etc. Anything else is not a good use of WG telcon time.

<AndyS> AndyS a +0.5 b -1 c +1 d -1

<DanC> HS: pref a, ok c

<DanC> PH: a +0.5 b -1 c +1 d -1

<DanC> DanC: (c)

<kendall> KC: Strongly dislike A & B; prefer C to D.

<DanC> Steve: c/d... can see lots of sides

<DanC> DanC: (b), rather

<DanC> Jeen: c, maybe b

<DanC> EricP: (a)

<jeen> (I am neutral on option a and strongly dislike d)

<bijan> Bijan: a -2, b -2, C +1, D +1(with some confusion), C&D +maybe

<Yoshio> Yoshio prefers (c). It's all up to the service policy, and that should be clearly stated in the service description. Against (d), it will put too much burden to small servers if it should be responsible for doing what is required

<DanC> DaveB: +c, -.5 d, unsure about b

<DanC> Lee: like c, dunno d, don't like b

<DanC> JanneS: c appeals, ; I'm OK with a

<JanneS> c, a, -b, -d

<franconi> Enrico: a -2, b -2, C +1, D +? (I don't get it fully yet)

<patH> my c vote is assuming we get the bnoide issue right.

patH: I think a lot of what we've been debating is how complicated the query treatment can be
... graph
... entailment node
... rigid bNodes
... can we embed all that in the choice of graph? Bijan opposes this.

DanC: we've invested 18 months in putting these in a single graph name

<patH> Wel, seems to me that most of what we have done works quite well if we allow these to be identified separately, which is why I voted for c.

ericP: i think both C and D will come from the client

Bijan: I'm more concearned with extensibility than with nailing down the current standards

<patH> +1

Bijan: we need to identify RDF semantics, and RDFS doesn't seem tough

PathH: FOAF uses Unique Name Assumption

ACTION: Bijan to work with Pat to come up with a proposal re rdfSemantics. ETA 2 weeks. [recorded in http://www.w3.org/2005/10/18-dawg-minutes.html#action13]