See also: proposed agenda, IRC log.
<DanC> Scribe: SteveH
chair reviewed WG membership
asemantics - not heard from for a while
u bristol - dave beckett
ntt - not heard from for a while
profium - no regrets from janne
testing actions continued without discussion
next meeting 19th july
scribe - EliasT
<kendall> oh, i have to send regrets for next week. Will be @ NASA touring rocket ships and stuff (at a SemWeb workshop, actually)
<DanC> DONE: ACTION: KendallC to ask Bijan to consider implications of answering bNode bindings with created URIs
ericp: assigning uris to bnodes
may bring up same issues as using a uri in the first
... do other approaches have the same problems?
kendall: I think we can rely on the syntactic hack (_!:...)
Chair went "round the table" regarding the potential new requirement:"it must be possible for a client to refer to a bnode provided by a server", occasionally refining the wording:
<DaveB> it sounds like session based to me
<DanC> "it must be possible for a client to refer to a bnode provided by a server... for some server-specified amount of time"
kendall: we intend to offer stability beyond session
duration of bnode stablity is server supplied?
<kendall> well, in some sense, yes, it's always server defined, whether it's explicitly specified or not.
<LeeF> In particular, because the duration could be "zero" for servers that don't support bnode stability.
<patH> Suggest it might be best to not talk of durations.
<kendall> +1 path
<patH> Suggests need to negotiate, etc., whereas surely all needed is to allow server to refuse to recognize a bnode as a name.
kevin: would like more discussion
<AndyS_> Should not define the stability and leave to impls.
<DanC> Yoshio? do you think the WG should spend more time investigating this requirement?
<Yoshio> dan, I'm not connected now
<Yoshio> but I don't think we should do so
kendall: we'd like to be able to do this, no need to require others to do it. wants to make sure not slammed in last call as we havent talked about it
<DanC> hmm... "servers must be allowed to provide bnode-referencable bnodes"
<LeeF> I prefer that wording.
I [SteveH] prefer it too
<Yoshio> I agree . I think it's upto servers (or services)
andy: "must be allowed to" is a noop, just aditing servers can do that it they want to, i dont think its a requirement. the earlier wording gives it too much weight, and we have to discuss it
<DanC> hmm... "SPARQL QL should include syntax so that servers can provide referencable bnodes"
<kendall> What about the language in the spec that Ron Alford quoted which seems to make it impossible to "allow to provide..."?
andy: have been proposals that require no changes
lee: what I took away is that it
would be ok to let it slide as long as the syntax allows
... important if [something..., broke up]
... more discussion needed
<EliasT> elias: same as Lee.
dan: I think it can wait
<LeeF> SteveH: Rest of what I said was that the discussion on the mailing list seemed to raise the issue that if the WG does not specifically address a requirement on this then there will be (are already?) wildly divergent implementations of bnode stability
<kendall> +1 to steve's torn-ness
<kendall> it ain't simple
eric: think its potentially dangerous, fair ammount of work to persuade ourselves that its dangerous or not
jeen: agrees with eric, whole
different set of issues in sparql as bnode syntax is allready
used, we included it for a reason
... should be an issue
jos: its clear that the scope is the graph, refering to it outside breaks rdf
<kendall> which notation did Jos mention?
jos: can use eg. path notation, we dont have much time, agrees with dan's position
<patH> suggest this can be handled by must/may language. Servers MAY recoignioze a bnode in a query as identical to one in an earlier response. But they are not oboliged to.
<AndyS_> Howard ref'ed another syntax hack which was <_:bnodelabel> because "_" is an illegal URI scheme. It allows more chars in bNode labels else much the same as _!: but no grammar change. Utilizes quoting of <>, no more.
<Yoshio> (not knowing what's going on in the voice track) I further think servers can provide such functionality without any change. they can just announce to their cliants that they can do that with conventional bnode labels(? name? whatever )
andy: there are designs that dont change the syntax[?], can use the illegal uri scheme and put it inside the quotes for uris
<DanC> <_:foo>? that's squatting on URI scheme space, no, andy?
andy: it allows you a wider choice of bnode labels, not concerned with the start of labels
thats how 3store implemeneted it by accident in RDQL
<DanC> no, not squatting.
<kendall> (quoting mechanisms are good things. IMO!)
andys: <_:foo> would be explicitly not a uri, equivalent to _:!foo
dave: it should be postponed, session related, thinks we will be looking at more session things in the next versions. postpone or reject
<patH> Guys,we don't need a new kind of name syntax. They are sztill bnodes, just the scope may be understood differently.
<AndyS_> <_:foo> can be done without WG help :-|
<patH> normal, scope=answer, possible scope=session. Up to server to allow or refust second option.
<DanC> pat, if you have an opinion on whether this requirement is worth more WG study before last call, it's in order now.
<kendall> I'd be perfectly happy with PatH's solution.
<DaveB> this might be related to multi-graph issues (named graphs), also in sparql.next()
andy: not introdcuing a new rdf term, there still bnodes, just scoped to something else
<patH> DanC, not sure where we currently stand, but think solution is farirly clear in outline.
<patH> Ok, point taken. Hmmmm, well, the 'right' way to go seems obvious to me, but I guess that is saying it needs more study.
<patH> Im OK to postpone, though I think it would be a pity.
<patH> Occurs to me we could still weaken the draconian wording that Kendall objected to orginally.
<kendall> That would work too; remember that our original position was just to strike that wording. That's it. Just let us do bnode stability and still claim compliance.
andy: bringing in session would impack the soap bindings
should spend more time: 1
+1 to striking wording
SELECT ?x WHERE (?x foaf:knows <_:genid.33553>)
^ example of bug exploit in 3store v2
incase anyone clear I [SteveH] *do not* like the <> approach
andys: can just be a convention
kendall: worried about that being different implementions
<DanC> _!:foo ?
<SteveH:> ex: label(?bnode, "label") is nicer IMHO
<ericP> SteveH, I refer to your ext:bNodeLabel(?x, "xyz") suggestion
eric: steve suggested ex:bNodeLabel using a filter function, I think it meets everyones requirements, do a query on a graph and subsitture stable bnodes. has all the semnatics we want from an extensible function, and has prescribed failure mode
kendall: i believe we could live with that, but I prefer the other one, think it does satisfy the requirements
eric: maryland's objection to ex: is that its a 2nd class citizen syntaxically
kendall: care more about being able to do this than interop.
<patH> If I follow this, the idea seems like a kludge. Bnode scopes are not set in stone, so why do we need to link bnodes to other ids just to alter their scopes?
eric: if we adopt it we have to define what it does
<kendall> i agree that bnode scopes are not set in stone
ericP: would you be happy is it was not defined
<patH> DanC: for assertions, yes, but not for queries. We can decide that.
<patH> DanC: to elaborate: consider a query/answer session as being all about a single graph. Then this makes RDF sense.
<DaveB> ref to ron alford's original message
<patH> Yes, well, that wording would nbeed to be changed.
<kendall> path: *exactly*!
eric: if we use a filter function we can leave the wording, its post the grpah query
<patH> Seems to me that the issue is all about scope of bnodes in queries. OPtions are : scope-query (default?) , scope=session. SUggest that servers may offer latter but are not required to, and that query may 'request' it by putting a bnode in some special p[lace in the query.
kendall: if thats true its interesting and might work
<AndyS_> Pat - bBodes also appear in  foaf:name "foo" which by the session rule does not match surely.
<DanC> "A blank node can appear in a query pattern. It behaves as a variable; a blank node in a query pattern may match any RDF term."
<patH> Well, not sure about that example, but the answer would be, if the query asks for session rule, and the server allows it, then it does.
dave: need to say that blank nodes in CONSTRUCT and SELECT are distinct from bnodes in data
<patH> DanC: in this proposal, that wouldbe the default normal query-based rule, but could be altered.
<patH> DaveB: why?
<DanC> replace both paras with: "A blank node can appear in a query pattern. It behaves as a variable; a blank node in a query pattern may match any RDF term."
<DaveB> patH:  in a CONSTRUCT template (blank node in an output graph) is different from  in a SELECT graph pattern (variable in a query)
<patH> Ah, I see. Well, I guess there would be no objection in principle to allowing bnode cooccurrence between construct and select, though I havnt thought through the consequencwes.
<DanC> PROPOSED: to replace 2 paras under 2.7 Blank Nodes, Blank Nodes and Queries with "A blank node can appear in a query pattern. It behaves as a variable; a blank node in a query pattern may match any RDF term." contingent on review by Kendall this week; and raise and postpone an issue on referring to bnodes from queries.
<patH> +1 proposal
<kendall> hell, i'm +2 on that proposal
RESOLVED, DaveB abstaining
<scribe> ACTION: Andys to make edit about bNodes [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action01]
<DanC> ACTION: KendallC to review new nbodes text [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action02]
<DanC> ACTION: DanC to raise and postpone issue on referring to bnodes from queries [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action03]
<DanC> ericp has some stuff he may send mail about
<DanC> ACTION CONTINUES: EricP to refine definitions extraction [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action04]
<DanC> ACTION CONTINUES: EricP clarify which regex lang, new section ericp; have AndyS check it. (in progress) [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action05]
<ericP> XML Schema regex lang
ericP: regex operator didnt have its own section, wnated text describing it, so got new function, makes swamp bigger, cries out for reorg, dan said can change order as long as the words dont change
<DaveB> I assume you refering to 18.104.22.168 fn:regex ?
ericp will leave the regex section asis
<DanC> ACTION: PatH to review new optionals defintions, if any. continues. [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action06]
<DanC> ACTION CONTINUES: DanC to write SOTD; work with EricP to publish [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action07]
danc: not much progress on status doc
andys: section 11, done my sections, found 1 thing thats probably a typo
eric: thinks it is a typo
<DanC> ACTION: EricP to fix typo in section 11 from Souri's comment, and one from AndyS [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action08]
kendall, would like cvs output sent to list
<DanC> ACTION: DanC to investigate having CVS commits send to the WG list [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action09]
<Zakim> kendall, you wanted to ask about the optionals issue
kendall, is the optionals discussion about 2 diff. ways to describe the same design, or do they have design differences
<DanC> very subtle and relevant question, KC... hard to say, from where I sit. test cases are welcome :)
andys: in theory no, but we cant prove that
<Zakim> DanC, you wanted to ask KC about relational algebra
danc: curious to know what the defn. would look like in relational algebra
kendall, standard db book has all this stuff in rel. alg.
kendall, "the database book" hector garcia ???, XXX, YYY
<DanC> Database Systems: The Complete Book (DS:CB), by Hector Garcia-Molina, Jeff Ullman, and Jennifer Widom.
yes, date is good
<kendall> i.e., I could be completely wrong
"An Introduction to Database Systems", C. J. Date
<patH> Yes, but beware: DBs don't have blank nodes in them.
<kendall> path: indeed
<DaveB> AndyS and I discussed some results format changes, looks like xsi:type is a PITA to keep around. also adding a <head><link> and moving the boolean results format format around
daveb: its important to have the schema document around when developing
daveb: potnetial change to results format
dave: and add something to allow
linking back to query
... were better off without XSI type?
<ericP> can the WG offer DaveB license to remove xsi:type at his discretion?
<ericP> i'm not sure we're done with it otherwise
<patH> Suggest we give Dave licence to ritually burn it as his discretion.
<DanC> ACTION: DaveB to update results actions w.r.t. boolean, xsi:type, link explain in email [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action10]
syntax-qname-08.rq and syntax-qname-14-rq
<DanC> JosD: .html isn't regenerated, but the test inputs and outputs are correct
<DanC> EP: I ran them.
<DanC> revision 1.4 2005/06/30 12:38:32; author: jderoo; state: Exp; lines: +1 -1. dot inside qname
-14 is revision 1.3
<DanC> PROPOSED: to approve syntax-qname-08-rq materials 1.4 and syntax-qname-14-rq 1.3
<DanC> so RESOLVED.
<DanC> ACTION: EricP to work with steveH to get .html test page to show approved status of syntax-qname-08-rq and syntax-qname-14-rq [recorded in http://www.w3.org/2005/07/12-dawg-minutes.html#action11]
Changes since 12 July call for review:
$Log: 12-dawg-minutes.html,v $ Revision 1.7 2005/07/12 21:40:31 connolly yoshio was on the phone for part Revision 1.6 2005/07/12 16:59:41 connolly cleaned up last three items Revision 1.5 2005/07/12 16:52:09 connolly - cleaned up discussion of bnode referencing - noted PatH and Yoshio on IRC - dropped an in-your-face URI link to agenda Revision 1.4 2005/07/12 16:37:56 connolly - added punctuationSyntax tests item to TOC - decluttered item 1 admin - moved Agenda, IRC log pointers under TOC; removed summary of actions - removed DRAFT, diagnostic foo - tweaked sig/address