A goal (dream?) of this meeting is to close all open issues and prepare for last call; or at least to plot a course to Candidate Rec.
Dan Connolly, chair
Ten working group members attended the
meeting, representing eight W3C member organizations, plus the W3C
Team:
Regrets were accepted from Hayes, De Roo, Katz, Raboczi, Adams, Wilkinson, Najmi, Thompson, Pollock.
for reference: registration
The meeting is in Espoo, Finland near Helsinki. See logistics details from the host for exact location, hotel accommodations etc. The local organizer is Janne Saarela janne.saarela@profium.com.
The usual #dawg IRC channel provides a small amount of remote access to the meeting (logs: Wed, Thu).
As discussed at the 11 Jan telcon, participants are expected to read the following documents in advance of the meeting and come prepared with comments. (Bonus points for putting your comments in email in advance of the meeting.)
DanC convened the meeting with nine participants in attendance (KendallC joined later). We RESOLVED: to amend 11 Jan minutes to note DONE: SteveH is willing to adapt his testing infrastructure to generate input/output RDF/XML and typed nodes into manifest file and then accept it as a true record. KendallC abstaining. We noted these done without discussion:
After some discussion of agenda, we postponed discussion of the SPARQL results set to a future meeting:
In preparation for the meeting, DanC updated the issues list to reflect all the proposals he could find and put together a issues WBS survey (derived by machine using GRDDL) to collect data about which proposals were acceptable and which were preferred. At the time the data was collected, the survey results were member-confidential. We considered publishing the data but it did not seem worthwhile to renegotiate expectations, clean it up, etc.
The survey was released a bit later than planned, so WG members had little time before the meeting to complete it. Also, the survey defaulted to "this is neither my preference nor is it acceptable" i.e. "I object" where in many cases the question simply hadn't been answered. ACTION DanC: to (with EricP) communicate WBS user experience to systems team.
Some responses were integrated into the agenda; more were collected during the meeting and integrated into the discussions.
DanC noted that this issue has little technical impact and is the sort of thing that he has more often left to the discretion of the editors, in consultation with other WG members.
proposals:
[1] Query ::= PrefixDecl* ReportFormat PrefixDecl* FromClause? WhereClause? A. SPARQL Grammar 1.140 28-Nov-04
supporting arguments:
supporting arguments:
opposing arguments:
After some discussion of the options above, we RESOLVED: to address issue prefixSyntax by limiting prefix declarations to one place in the grammar, at/near the beginning. KendallC abstaining.
postscript: there were no actions assigned to the spec editors nor test suite editors. Oops
motivated by PRIME use case
Let me strongly suggest that we do not include UNSAID in SPARQL. ...
Note a relevant objective:
It must be possible to query for the non-existence of one or more triples or triple patterns in the queried graph. objective 4.3 Non-existent Triples accepted 2004-07-15
DanC noted a connection between UNSAID and SOURCE, in that they both involve the input to a query being more than just an RDF graph; the DataSet notion in the current QL draft has a background graph plus a set of name/graph pairs. Strictly speaking, this only applies to UNSAID designs where queries can express "does graph G not say S/P/O?"; noone advocated designs that cannot do that.
SteveH claimed that the simplest form of unsaid can be done with optionals; evaluation/elaboration of this claim revealed that a BOUND function/operator/keyword was also involved, ala isBound in section 11.2.2 SPARQL specific operations as of v1.171:
select ?x where (?x rdf:type :Person) [(?x ex:phone ?phone)] AND !bound(?phone)
DanC re-iterated his concerns with such operators, noting issue useMentionOp: str-less-than(?x, "abc") does not compare the two character string ?x with the 5 character string "abc" but rather compares what ?x is bound to with the three character string abc. DanC argued against taking us out of the scope of positive conjunctive queries against RDF graphs.
After it was generally accepted that UNSAID and optionals with BOUND have the same expressive capability, SteveH argued that BOUND can be straightforwardly translated to SQL in such a way as to exploit SQL query optimizers, while he did not see a way to do that with UNSAID; moreover, users were less likely to write difficult-to-optimize queries with UNSAID. BOUND seemed easier to teach and learn to several WG members, as well.
Discussion of how to specify BOUND touched on various calling conventions in programming languages such as call-by-value, call-by-reference, call-by-name, etc.
Exploration of XQuery functions and operators specs ( near F&O string matching) revealed:
If the atomized operand is an empty sequence, the result of the arithmetic expression is an empty sequence
<AlbertoR> Unicode Case Mapping document
DanC suggested specifying BOUND as a straightforward mapping from a solution and a variable name, and this seemed to avoid the calling convention issues.
Examination of some examples from EricP suggested that some sort of op:URIequals is probably needed in addition to isBound().
This led to discussion of operators to relate URI terms to strings. DanC explained that the swap/cwm/n3 design uses log:uri as a use/mention level-breaker:
{ <http://example> log:uri "http://example" }
Brainstorming on how to say this in SPARQL included an example:
uri(?y) =~ "http://example"
... which prompted discussion of casting, implicit or explicit, including consideration of some examples:
While DanC continued to argue that use/mention operators were different from casting, consensus was building around the BOUND design.
EricP conducted some grammar experiments using a grammar wiki for sparql; e.g. see PrimaryExpression, grammar with BOUND and no UNSAID
DanC PROPOSED: to address useMentionOp and UNSAID issues ala: name() fn to map URIs to strings; BOUND keyword; no UNSAID. and =~ does not apply to URI terms. DaveB offered smaller proposals: PROPOSAL: str(fn) to map URIs (and other things) to string. PROPOSAL: BOUND keyword and no UNSAID to address common UNSAID issues.
Eventually, we RESOLVED: BOUND keyword and no UNSAID to address common UNSAID issues. KendallC abstaining
In discussion of name() or str(), DanC acknowledged a new issue, valueTesting, to collect discussion of functions and operators.
When asked about the case of AND 1.5 == 1.4999999999999999 the editors did not think that rq23 v1.171 clearly specifies how it works.
AndyS noted a relevant SemWeb best practices draft, especially a section on equality.
DanC suggested treating mathematical inferences like RDFS and other inferences:
select ?x where 1 math:equal 1. # lose
select ?x where 1 math:equal 1. # win
and noted the correspondence between ... AND ?x + 1 < 3 and { [ is math:sum of (?x 1)] math:lessThan 3 } but discovered that it involves literals as subjects and withdrew the suggestion.
We then RESOLVED: to use str(fn) to map URIs (and other things) to string and =~ does not implicitly cast URIs to strings (nor do other operators). KendallC abstaining ACTION EricP: to update rq23 w.r.t. str(). ACTION SteveH: to propose tests for str() and =~. ACTION EricP: to update rq23 w.r.t. BOUND/UNSAID. ACTION DaveB: to draft tests for BOUND (based on ericp's examples)
<DanC_lap> Lunch...
<DanC_lap> resume at 1:30p
It should be possible to constrain a query with regard to the source or sources of a triple or triple pattern. 4.2 Data Integration and Aggregation
After noting a certain amount of support for the "untrusted graphs" design specified in v1.166 of the editor's draft, we reviewed a SOURCE design from SteveH and discussed this example:
SteveH proposed that the there be 3 answers: ?c binds to c1, c2, c3 (v1.166 says there is one: c3). He gave a supporting use case: looking for an rdfs:label value for a uri, for presentation purposes; matters little where it came from
EricP supported this design, noting that Annotea has multiple graphs (they can be named or not) and default search returns 3 answers in this case.
We reviewed...
Definition: RDF Dataset
An RDF Dataset is a collection of RDF graphs comprising a single, unnamed graph, and a collection of named graphs. Graph names are URI References (URIrefs)
SPARQL Query Language for RDF v 1.166
There was some discussion of what is to call the default/background graph (when there's no SOURCE); suggestions included default query graph, background query graph, background knowledge base. Discussion seemed to settle on "background graph".
Steve and EricP argued that the background graph should be constrained to include all the named graphs. AndyS pointed out that we then cannot express some of the trusted/untrusted graphs examples from timbl (the log;semantics/includes stuff), and suggested that as the spec (1.171) is written, 3store can offer a service where the default/background query graph includes rdf-merge [union] of all graphs it knows.
SteveH pointed out that the test manifests cannot currently express this flexibility. DanC suggested :t1 t:dataset (<bg> (<n1> <g1> <n2> <g2>)). After general agreement that this should be fixed, we RESOLVED: to revise "unnamed" terminology, enhance test manifest, and adopt the design in the tests tests/data/source-named/ and source-query-001, 2 3 & 5 [...] (note FROM/GRAPH are hints w.r.t. SOURCE) (test bytes to be approved later). ACTION AndyS: to revise "unnamed" terminology. ACTION SteveH: to revise test manifest w.r.t. "background" and named graphs. ACTION DaveB: to propose source test to approve
With regard to "ACTION: JanneS propose text for hard failure in the protocol draft", AndyS explained that the design gives just one answer for each input and query; there are no optional features in that sense. Janne was satisfied; the action is WITHDRAWN.
ACTION DanC: suggest formal definitions for SOURCE continues.
SteveH argued that FROM and GRAPH shouldn't be in QL, they belong in an API or command-line option or some other layer.
We noted the lack of a test for using a source ?var in a constraint, though SteveH had an example.
DanC picked out a number of positions from the discussion and polled for support several times; the (approximate) data from the last (non-binding) poll were:
DanC asked if the protocol spec took a position on this issue. We found some relevant text:
The query processor uses the URI to build an RDF dataset [added to the background knowledge base]. Some processors may choose to allow multiple URIs in the FROM clause. These are used to create a single graph by RDF merge. section 8.1 of SPARQL Protocol WD 20050114
We explored designs for standardized FROM/GRAPH handling.
LOAD <uri>, <u2>, <u3> adds into background graph.
FROM <u1>, <u2>, ... gets the contents (per uri/http...) and makes them available as named graphs
and ... WHERE GRAPH ?g (?who knows ?whom)
Discussion consumed the remainder of the day without conclusion. The IRC log starting 12-56-31 includes some details.
We recessed for the evening.
We noted SPARQL Protocol for RDF W3C Working Draft 14 January 2005 discharges ACTION: EricP/KendallC to publish "SPARQL Protocol for RDF" pending approval from TomA and AndyS. ACTION KendallC: Announce the protocol spec
Regarding the Abstract protocol, DanC noted that it comes with a testing obligation; if we're only going to test one concrete protocol, we should fold the essential material from the abstract protocol into it. He later clarified that it would be OK if a second concrete protocol (SOAP, SMTP, ...) were not normatively specified, but only specified in a Note or even only in the test materials; as long as the abstract protocol "hook" is tested, we've met our obligations.
postscript: this bit of SpecGL seems relevant, though not exactly the "untested hooks are bad" bumper-sticker I'd like to see:
Make sure there is a need for the optional feature. 4.2 Good Practice A: in 4. Managing Variability of SpecGL
Kendall suggested that we get involved in a SOAP binding, since it's likely to happen anyway and might not turn out the way we want unless we get involved. EricP noted SOAP mappings to HTTP GET; that is WSDL support for GET that returns a SOAP envelope. DanC wondered if the SOAP data model could express query results (set of pairs...); a quick investigation was inconclusive. ACTION EricP: to inviestigate WSDL/SOAP encodings of SPARQL protocol.
DanC summarized the issue as: in the case of no query string, what does a GET return? He observed two designs:
Kendall said he prefers not to constrain this aspect of the protocol.
SteveH said that in practice, his service returns an HTML form to query the graph. DaveB expressed a preference for "GET /uri => service description".
Kendall suggested we explore the HTTP OPTIONS method for getting service descriptions. DanC noted this doesn't facilitate bookmarking/linking service descriptions, which seems important. Alberto asked if it works, in practice, thru firewalls. DaveB reported that the MS WEBDAV client does OPTIONS on the root. JanneS noted...
Responses to this method are not cacheable. RFC2616 section 9
In order to move on to discussion of service description, DanC observed that Kendall seemed to have a clear position on this issue and asked that he lead a discussion in email. ACTION KendallC: to propose a solution to protocolRootReferent. DanC clarified that yes, using the editor's draft to propose a solution is fine.
Regarding service descriptions, DanC suggested we step back a bit to the usecase/requirement level, using a pragmatic approach: stick to describing capabilities of services that we have first-hand experience with. We discussed a few scenarios:
Kendall noted "WSDL 2 RDF" mapping work; suggested that while we (DAWG) are further ahead in our schedule, there is a risk of premature standardization if we just make up vocabulary terms without considering other work. DanC suggested that the risk is manageable and that we should do something in this design space; formalize what we know we want: e.g. RDQL and SPARQL, RDFS closure. He suggested, as "homework," that those with services sketch service descriptions of them. ACTION SteveH: Write up a service description of features supported for his service. ACTION KendallC: Add section for service descriptions and put graph specifying in it to start it off
There was a somewhat inconclusive discussion of whether our specification or webmasters should have ultimate say over HTTP ?param= names. ACTION DanC: write up "sparqlParam" approach
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK (?x foaf:name "Alice" )section 10.4 Asking "yes or no" questions v1.133 17-Nov-04
After a short discussion of the above options, we RESOLVED: to add explicit yes/no in result set; keep boolean in protocol spec; keep ASK syntax and section 10.4 Asking "yes or no" questions as from v1.33 17-Nov-04 and later version of the QL spec; DanC, SteveH abstaining.
lunch...
In response to a question about how many face-to-face meetings we should expect in the year starting April 2005, DanC suggested that after the W3C Technical Plenary, we are aiming for CR in April; we might have one more face-to-face meeting to work on testing or otherwise prepare for Propose Rec. At some point, perhaps in the fall, we should be able to go to a "low intensity" mode where we have teleconferences perhaps once a month. Then perhaps a face-to-face meeting early next year, though it may be a "what to do next" workshop of some sort, rather than a meeting of this WG. A poll of the participants showed they expected between 1 and 4 meetings in the Apr 2005-Apr 2006 year, with 2 being the most common answer, and several endorsing the "low intensity" period and the "what to do next" meeting ideas.
When discussion revealed that several WG members were planning to attend XTech in Amsterdam in May, Alberto suggested we co-locate a WG meeting. ACTION AlbertoR: to propose a f2f meeting in Leiden (since done 31 Jan). SteveH suggested Manchester as a nearby option.
Where the charter calls for Last Call in January 2005 and recent discussions revised this estimate to Feb 2005, we observed that 17 March is the earliest realistic target for last call publication (ftf meeting 28 Feb-1 March; a couple weeks editing work; WG telcon to decide on 15 March, resulting in publication 17 Marh).
I like this sort of design where this feature as a completely separate query language. Connolly 20 Jul 2004
Alberto reported on experience using DESCRIBE to support a Z3950 interface
DanC supported DanBri's proposal, arguing that any implementation of DESCRIBE can be converted to work as DanBri describes by adding rdfs:seeAlso links. Discussion revealed that this would involve a lot of such links; one for every potential query.
DanC argued that the expectations around DESCRIBE are very different from CONSTRUCT and SELECT, and hence it should be specified in a separate query language, but others were comfortable having it in the same language. There was some question as to whether a trivial implementation, that always returned an empty graph, was correct. This does seem to be as designed. Further discussion did not seem likely to persuade anyone; we RESOLVED: to keep the DESCRIBE syntax from SPARQL Query 10.3, over an objection from DanC, with KendallC, SteveH, and DaveB abstaining..
Oops; we neglected to action someone to respond to DanBri.
DanC asked for any news re DawgShows.
DaveB reported recent implementation experience with options; we looked at an example of Rasqal's optional support.
AndyS noticed an interaction between parts of the spec... ACTION AndyS: to propose test case re optionals and ordering.
WITHDRAWN: ACTION KendallC expose our walking tour data to SPARQL querying clients
KendallC reported on an upcoming NASA interop event: SPARQL interop may be the best thing to demo. Rough deadline someplace in August 2005.
DanC noted, with regret, that TomA, who had offered to be a 1st line of comment handling, is no longer participating in the WG, and asked if an unspecified/chaotic process for handling comments seemed sufficient until we get to Last Call. DaveB has subscribed to the comments list, since he serves as editor of one of the WDs.
KendallC reported, re Tucana, the Tucari developers are continuing at sourceforge. they claim ITQL is a superset of SPARQL and to have faced stuff that we'll be facing soon.
EricP explained his recent work on a grammar wiki for experimenting with syntax, and advocated N3/turtle style on the grounds that it facilitates taking turtle data and turning it into a query and/or a CONSTRUCT clause. Alberto and SteveH argued that the RDQL style syntax was straightforward to teach and learn for a growing user base.
We constructed some examples, in preparation for a straw poll:
SELECT *
WHERE { ?p ?s ?o }
##
PREFIX foaf: <http://example/foaf#>
SELECT ?me ?you
WHERE { ?me foaf:knows ?you. ?you foaf:knows <fred> }
##
PREFIX foo: <http://www.w3.org/>
SELECT ?p ?o
WHERE { ?s ?p ?o . ?o ?p2 ?o2}
##
PREFIX foo: <http://www.w3.org/>
CONSTRUCT { ?s foo:bop ?o2 .
?o2 foo:bing ?o }
WHERE { ?s foo:bar ?o .
?o foo:baz ?o2 }
DaveB and DanC summarized the N3 style proposal as
The N3/turtle [] syntax was not proposed.
The last of a series of straw-polls showed that a discussion between the editors and the WG members was not reaching consensus:
DanC observed that settling this matter soon was critical to meeting our schedule goals, so he put the question and we RESOLVED: to adopt the syntax of 1.171 SPARQL draft over the objection of EricP and with KendallC abstaining.
Oops; we didn't action anyone to get back to TimBL.
DanC observed that while there are occasional requests for handling collections conveniently (e.g. Herman 24 Oct), we haven't really discussed any designs yet, and suggested that perhaps we should postpone. Each participant was asked for his view:
DanC observed that PatH seems to have a proposal coming imminently and as such felt we should wait just a bit before postponing. In a week we'll either have good reason to talk more or we won't. ACTION DanC: to propose to postpone accessingCollections
If a graph template is supplied, then the RDF graph is formed by taking each query solution and substituting the variables into the graph template and merging the triples into a single RDF graph. section 10.2 Constructing an Output Graph
1.162 (aseaborn 06-Jan-05)
DanC noted that this issue was added to the issues list when a requirements discussion got into design details about the correspondence between bindings and graph solutions and is handled pretty straightforwardly in recent drafts. We quickly RESOLVED to close graphSolutionMapping per SPARQL 1.162/1.171
DanC asked how nested optionals extends the expressive capability of the language. We discussed an example:
PREFIX foaf: &http://xmlns.com/foaf/0.1/> PREFIX vcard: &http://www.w3.org/2001/vcard-rdf/3.0#> SELECT ?foafName ?gname ?fname WHERE ( ?x foaf:name ?foafName ) [ ( ?x foaf:mbox ?mbox ) ] [ ( ?x vcard:N ?vc ) ( ?vc vcard:Given ?gname ) ] [ ( ?vc vcard:Family ?fname ) AND BOUND ?vc ]
DanC sensed some consensus to adopt sparql rq23 v 1.171 as addressing nestedOptionals, but putting the question showed an unexpected number of objections; the question did not carry. KendallC explained his objection: it's too hard to read/understand. Benefits outweighed by the cost. I'd be willing to merely abstain if the syntax were less confusing/ugly/hard-to-teach DanC had curtailed syntax discussion on the grounds that it was asked an answered in the punctuation syntax item.
Discussion yielded a new proposal: a side condition on the grammar to prohibit nested optionals. A poll showed no clear consensus:
Discussion was inconclusive.
If a triple template has a variable, and in a query solution, the variable is unbound, then the substitution of this triple template is skipped but other triple templates are still processed for the same solution and any triples from other solutions are included in the result graph. An error or warning may be generated. section 10.2 Constructing an Output Graph
1.162 (aseaborn 06-Jan-05)
Discussion included use cases where an unbound variable was intended by the user -- e.g. with optionals -- which suggests that an error is inappropriate. DaveB wondered about how to express warnings in the results... rdf/xml comments, x-http-, n3 comments...
We RESOLVED to address consUnboundVars by changing "... may issue an error or warning... " to "... may issue a warning..." in section 10.2 Constructing an Output Graph, and discussing warnings in protocol and result set specs (xml comments, http headers, etc.) ACTION AndyS: change "... may issue an error or warning... " to "... may issue a warning..." in section 10.2 Constructing an Output Graph. ACTION DaveB: discuss warnings in result set spec. ACTION KendallC: discuss warnings in the protocol spec.
A template can create an RDF graph containing bNodes, indicated by the syntax of a prefixed name with prefix _ and some label for the local name. The labels are scoped to the template for each solution. ...
section 10.2 Constructing an Output Graph
1.133 (aseaborn 17-Nov-04)
DanC asked AndyS if he was more or less confident than when he wrote To be discussed .... AndyS replied that he is more confident. Regarding Sandro's comment, he gave a use case that needs bnodes in the CONSTRUCT clause: querying foaf data and constructing vCard data.
We RESOLVED: to close consUnboundVars ala section 10.2 Constructing an Output Graph v1.133 / 1.171.
Oops; neglected to action someone to respond to Sandro.
After a review of the history of the issue, and discussion of SQL union and some discussion of the interaction with SOURCE (now GRAPH), there remained some disagreement about whether this should be a requirement at this stage and whether it was worth the implementation cost. In the interest of keeping to schedule, we RESOLVED: to resolve disjunction issue ala v 1.171 of rq23 section 6 More Pattern Matching -- Alternatives over the objection of DaveB, with SteveH, Yoshio abstaining.
After EricP reviewed an algae federation use case and a brief discussion, we RESOLVED: to postpone cascadedQueries; while federation use cases are interesting, the designs don't seem mature and the use cases are not urgent; with KendallC abstaining.
newly acknowledged during discussion of unsaid and useMentionOp; re section 11 Testing Values
DanC observed that the design space here is enormous, and the XML Schema and XML Query WGs have spent a lot of time on it, so our job is to integrate relevant parts of their work, not to have an independent design discussion.
DanC then suggested that spending a few more weeks on this is not likely to improve our design much, and suggested that we start with a handful of integer and string operations. JanneS asked about dateTimes with timezones. AndyS argued against duration in any case. EricP made a proposal:
Regarding numeric types, AndyS noted that owl uses (arbitrary precision) integers; suggested we start with double, decimal, integer. DaveB noted xquery says implementation defined precision, not arbitrary precision:
For xs:decimal values the number of digits of precision returned by the numeric operators is implementation-defined just before end of 6.2
EricP and others (KendallC) expressed reservations about deciding today; EricP offered to research and propose. DanC noted that if we get new information we can re-open the decision; he put the question and we RESOLVED: to address valueTesting by choosing datetime, date, time; date less-than, date-greater-than, date-equal; string ops per 1.171; numeric double, integer, 9 numeric ops above, per xquery f&o with EricP, KendallC, SteveH abstaining.
RESOLVED: to thank the hosts, Profium, especially Janne Saarela and Outi Mäenpää.
since v1.49, cited in 2 Feb call for review
$Log: ftf4.html,v $ Revision 1.56 2005/02/07 15:20:36 connolly star'd issues closed over objection Revision 1.55 2005/02/07 13:36:01 connolly fixed CVS keywords at the top Revision 1.54 2005/02/04 19:53:15 connolly - split useMentionOp item from unsaid item - summary indicates closed issues - formally connected issues to discussion items Revision 1.53 2005/02/04 19:22:47 connolly one more spell-o Revision 1.52 2005/02/04 19:22:07 connolly spell-checked Revision 1.51 2005/02/04 19:16:34 connolly added photo (thanks, KC)