RDF Data Access -- 12 Jul 2005

Convene, take roll, review records and agenda

<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

ACTION: SteveH to review the relevant test case re: IRI normalization
ACTION: EricP to pair with SteveH on making the HTML test results page
ACTION: DaveB to to propose source test to approve
ACTION: DanC to follow up re optional test based on op:dateTime triple
ACTION: SteveH to prepare test cases for publication as WG Note (no deadline/urgency)
ACTION: AndyS to add the above graph test cases (analagous to valueTesting test cases) (don't expect quick delivery)
ACTION EricP: finish extendedType-eq-pass-result.n3 test

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)

new requirement on handling bnodes?

<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 place
... 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 it
... 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

steve: torn

<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.

<patH> refust/refuse

<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

poll...

should spend more time: 1

+1 to striking wording

<patH> +1

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

<DanC> http://www.w3.org/2001/sw/DataAccess/rq23/#BlankNodes

<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

<ericP> +1

<kendall> hell, i'm +2 on that proposal

<jeen> +1

objections: 0

anbsensions: 1

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

SPARQL QL publication

<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 11.2.3.6 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

<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

<ericP> +1

results format, schemalocation

<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

<DanC> http://www.w3.org/2005/06/sparqlResults

<patH> Suggest we give Dave licence to ritually burn it as his discretion.

<DaveB> heh

<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]

punctuationSyntax tests

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]

RDF Data Access

12 Jul 2005

Attendees

Contents/Agenda

Convene, take roll, review records and agenda

new requirement on handling bnodes?

SPARQL QL publication

results format, schemalocation

punctuationSyntax tests

Changes