RDF Data Access Working Group Meeting, 19-20 January 2005

hosted near Helsinki, Finland by Profium

on this page: Venue * Participants * Reading List * Agenda * Minutes * Changes
nearby: charter * issues * public-rdf-dawg archive * logistics details * irc Wed, Thu
fun with MeetingRecords: formalized (RDF) record, Makefile

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
with thanks to the scribes: JanneS, DaveB, AndyS, EricP, SteveH
and to David Booth's scribe.perl version 1.109 (CVS log)
$Revision: 1.56 $ of $Date: 2005/02/07 15:20:36 $


Ten working group members attended the meeting, representing eight W3C member organizations, plus the W3C Team:

  1. Asemantics S.R.L.
    • Alberto Reggiori (aka AlbertoR; intro. near Milan, Italy)
  2. Bristol, University of
    • Dave Beckett (aka DaveB; intro. near BRS)
  3. Hewlett Packard Company
    • Andy Seaborne (aka AndyS; intro. near BRS)
  4. Maryland Information and Network Dynamics Lab at the University of Maryland
    • Kendall Clark (in part) (aka KendallC; intro near College Park, Maryland, USA, DCA)
  5. Matsushita Electric Industrial Co., Ltd. (MEI)
    • Yoshio Fukushige (aka Yoshio; intro; near Tokyo, Japan)
  6. Nippon Telegraph & Telephone Corp. (NTT)
  7. Profium Ltd.
    • Janne Saarela (intro. near Espoo, Finland)
  8. Southampton, University of
    • Stephen Harris (aka SteveH; intro; near Southampton, United Kingdom)
  9. W3C
    • Dan Connolly, chair (aka DanC; intro. near MCI)
    • Eric Prud'hommeaux, team contact (aka EricP; intro. near NRT)

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

Preparation: Reading List

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

Agenda Topics and Action Summary

  1. Convene, take roll, review records and agenda
    • ACTION DaveB: discuss options for column ordering and pick one
    • ACTION DaveB: to post announcement about XML result set on appropriate mailing lists
    • ACTION DanC: ask Liam, via SemWeb CG, which XML groups might be interested in SPARQL result set WD
  2. Issues Poll
    • ACTION DanC: to (with EricP) communicate WBS user experience to systems team.
  3. prefixSyntax closed
  4. unsaid issue closed
  5. useMentionOp issue closed
    • 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)
  6. SOURCE issue closed
    • 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
    • ACTION DanC: suggest formal definitions for SOURCE
  7. fromUnionQuery issue
  8. SPARQL Protocol Spec
    • ACTION KendallC: Announce the protocol spec
    • ACTION EricP: to inviestigate WSDL/SOAP encodings of SPARQL protocol
  9. protocolRootReferent issue
    • ACTION KendallC: to propose a solution to protocolRootReferent
  10. Service Descriptions
    • ACTION DanC: Write up definitive service concept
    • ACTION KendallC: to think about predicate to relate html-forms and svc descriptions, and how this goes into the spec
    • 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
    • ACTION DanC: write up "sparqlParam" approach
  11. yesNoQueries issue closed
  12. WG Schedule (ftf meetings, last call, CR)
    • ACTION AlbertoR: to propose a f2f meeting in Leiden
  13. DESCRIBE Issue closed*
  14. Services (DawgShows)
    • ACTION AndyS: to propose test case re optionals and ordering
  15. NASA Interop Event
  16. Handling Public Comments
  17. SPARQL punctuation syntax
  18. accessingCollections issue
    • ACTION DanC: to propose to postpone accessingCollections
  19. graphSolutionMapping closed
  20. nestedOptionals issue
  21. consUnboundVars issue closed
    • 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.
  22. consWithBnodes closed
  23. disjunction closed*
  24. cascadedQueries issue closed
  25. valueTesting closed
  26. Thanks to Profium for hosting


Convene, take roll, review records and agenda

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:

Issues Poll

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.

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

unsaid issue

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

useMentionOp issue

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:

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

SOURCE issue

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:

Graph <g1>
:a :b :c1
Graph <g2>
:a :b :c2
:a :b :c3
SELECT ?c WHERE (:a :b ?c)

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.

fromUnionQuery issue

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:

hint (0 supporter; 3 strongly opposed)
FROM/GRAPH are hints
std (3 supporters; one strongly opposed)
FROM/GRAPH are well-defined instructions that interact with the web per URI specs
ext (3 supporters; 2 strongly opposed)
drop FROM/GRAPH; leave them to system-specific mechanisms

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.

FROM/GRAPH specify the minimum of the background graph; a system may add more
FROM may add named graphs as well as background; GRAPH must.
drop GRAPH. FROM may add named graphs.
1.171 FROM becomes LOAD. 1.171 GRAPH becomes FROM. 1.171 SOURCE becomes GRAPH.

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.

SPARQL Protocol Spec

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.

protocolRootReferent issue

DanC summarized the issue as: in the case of no query string, what does a GET return? He observed two designs:

  1. a service description
  2. the whole background graph

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.

Service Descriptions

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

yesNoQueries issue

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.


WG Schedule (ftf meetings, last call, CR)

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


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.

Services (DawgShows)

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

NASA Interop Event

KendallC reported on an upcoming NASA interop event: SPARQL interop may be the best thing to demo. Rough deadline someplace in August 2005.

Handling Public Comments

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.

SPARQL punctuation syntax

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:

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

  1. (a b c) (d e f) becomes { a b c . d e f }
  2. semi ; between predicate/object pairs sharing a subject
  3. comma , between objects sharing a subject and predicate

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.

accessingCollections issue

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:

no immediate need for this feature
somewhat conflicted; despite user requests, I think we should postpone due to lack of experience.
haven't needed it, wont miss it right away, whats a typical use case? find simple solution?
what i did in algae is a hack, if there's a certain flag set and you ask for something that points to a list it searches for anything in that list - works for testcases, but never had RW scenario
... no thoughts on what WG should do
prefer having something, but if we don't have a solution handy yet, it seems hard.
not urgent/critical for query right now
collections not in our problem space, not interested in solution urgently; could eventually use DESCRIBE for this
Based on A Comparison of RDF Query Languages, it seems that only one path language does it. I don't use it; we can't rush into it; needs a lot of thought; we shouldn't start now as there is no proposal
thing it's not fatal not to do it, but we will miss out part of the community... there's a chicken and egg problem... some don't use SPARQL because you can't access collections easily. I see two solutions: member-of property - would be 1st prop we (DAWG) have to create; or special binding function member_of(). We have to make conscious decision in order to respond to inevitable comments.
I'm pretty sure I'd object to any proposals at this point; I don't have time to get experience to make me confident about any proposals in the near term.

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


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

nestedOptionals issue

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.

consUnboundVars issue

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.


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.

cascadedQueries issue

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.


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:

  1. (6.2.7) op:numeric-unary-plus
  2. (6.2.8) op:numeric-unary-minus
  3. (6.3.1) op:numeric-equal
  4. (6.3.2) op:numeric-less-than
  5. (6.3.3) op:numeric-greater-than
  6. (6.2.1) op:numeric-add
  7. (6.2.2) op:numeric-subtract
  8. (6.2.3) op:numeric-multiply
  9. (6.2.4) op:numeric-divide
  1. (7.2.3) op:compare
  2. (7.2.4) op:matches

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.

Thanks to Profium for hosting

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

Revision 1.51  2005/02/04 19:16:34  connolly
added photo (thanks, KC)