July 2004 RDF Data Access Working Group Meeting in Carlsbad, California

Minutes

Convene, admin

The meeting began with roll call; see participants above.

RESOLVED: to approve the 6 July minutes as a true record.

Whereas the W3C Advisory Committee meeting has been scheduled for the 1st week of December, 2004, we RESOLVED to unschedule our 1-2 Dec RDF Data Access WG meeting. ACTION EricP: find out the schedule of the 2005 W3C tech plenary and inform the WG so that we can plan ftf meetings after September.

Issue-driven, test-driven specification development

DanC suggested following an issue-driven specification development process, using tests to characterize and resolve issues, once a strawman design has been chosen. A number of risks were discussed:

Feature creep: closing issues by adding features, resulting in an overly complex design. Test-driven development is supposed to give us a certain amount of "design courage" to refactor the design to maintain simplicity.

churn: there is a bootstrapping problem with articulating tests in the language, except some tests and new features change the language. Tests may have to be rewritten, perhaps repeatedly. We can start with natural language descriptions of tests; but eventually we'll want an automated, machine-processable test suite, so that other folks can interact with them.

We'll also need a protocol testing mechanism, which may be somewhat involved.

In discussion of maintenance mechanics, we noted that ericp, yoshio, jos, dan, andy, kendall have cvs write access.

EricP is handling the issues list but he'd like to have some help. Later, KendallC expressed interest in maintaining the issues list, provided UC&R stabilizes.

Initial Design positions

DanC noted that the initial design straw poll showed a critical mass of support for BRQL/RDQL and invited each participant to give their position on the strawman query language design. DanC noted part way thru that the input to the automated poll was internal to the group; WG members who wanted their comments on the public record would need to re-iterate them or forward them. The following notes are likely incomplete:

RobS supported XQuery-based designs and opposed BRQL.
AndyS supported BRQL, arguing that XQuery-based designs leave too much of the burden on the app developer, and don't straightforwardly express RDF queries.
SimonR advocated the simple WHERE clause in RDQL.
JosD finds rdql/brql workable, but prefers n3ql because it's "all in triples". Jos asked about having brql as a strawman and an n3ql serialization.
YoshioF supported brql and n3ql
HiroyukiS leaned toward brql, with some reservations related to integration with higher levels of the semantic web architecture.
HowardK advocated xsrql.
DanC supported RDQL, with its straightforward WHERE clause, argued that parts of BRQL seem to be premature standardization, but expressed confidence that WG review starting with BRQL would lead to a satisfactory result.
EricP expressed concerns about a false sense of familiarity among end users for a language with sql-like syntax, and about about federation tradeoffs; he still prefers algae, finds n3ql acceptable.
KendallC had little to add over the comments he had submitted in the form, and noted XQuery would be expensive to add to his implementation; argued that when convincing real world people to use [dawg-ql], even a false-sense of familiarity is helpful; expressed a preference for RDQL or BRQL based on implementation experience with the [RdfDB] family of designs.

In response to comments about the connection between these design and rules, DanC noted that the work of this Working Group might usefully be informed by a W3C Workshop on rules, such as the the Semantic Web Coordination Group has discussed from time to time.

Non-RDQL design centers: XQuery, Rules

TomA and DaveB joined remotely.

HowardK gave brief live demo of XsRQL: an XQuery-style Query Language for RDF and discussed implementation and timeframes. The raw irc log captures a bit of the technical discussion.

DanC noted N3QL's motivation is integration with rules, diff, etc., to which AndyS argued for a separation of functionality concerns from syntax concerns. SimonR asked whether, if we have graph results, are we not doing a (simple) rules language? DanC answered that yes, that's a limited form of rule; more generally, horn clauses allow the body of the rule to be a different shape from the head. AndyS added that rules systems can include the feature of results feeding back into the KB.

ACTION Simon+Kendall elaborate the rel. of rules and "construct" in the UC&R doc.

RobS noted universals seem to have few precedents in extant languages. e.g. "someone all of whose girlfriends are attractive" is hard to express.

The relationship between OWL and rules came up in discussion; a paper by Grosof and Horrocks, Description Logic Programs: Combining Logic Programs with Description Logic was recommended by several WG members.

The group discussed a premise mechanism, such as discussed in a note from YoshioF. RobS noted that iTQL has a similar mechanism, called given. EricP noted related features in Algae. ACTION EricP: offer implementation experience (perhaps in use case form) with premises and algae. done? annotea use case

Then we broke for lunch and ad-hoc technical discussion. The irc log starting 21:03:48Z includes a few notes.

Resolving pending requirements

The group discussed requirement 3.6 Optional Match. A message from SimonR advocating the requirement discharged his earlier action.

EricP reported mixed opinions from W3C's semantic web advanced development group: TBL opposed, DanC worries about the time cost; EricP has been persuaded it is needed. RobS argued against putting it on the critical path as a requirement. YoshioF noted the risk that if we don't standardize it, the market will meet the need in incompatible ways. DanC asked for new arguments that had not yet been discussed, and there were none. Observing a critical mass in favor he put the question and we RESOLVED to adopt requirement 3.6 Optional Match as phrased in version 1.123, over the objection of RobS of Network Inference and JosD's abstention.

Regarding "3.8 Bookmarkable Queries", DanC apologized for the tardiness of his action and asked about moving it to an objective. A strawpoll showed several in favor. We subsequently adopted an amended version as an objective.

The group discussed "3.10 Result Limits". The synergy with sorting was noted. After discussion of the implementation costs of sorting and the trade-off between client and server compute power per user, opinions differed on the merit and/or necessity of limits without sorting. Library systems and other interactive systems were suggested as supporting use cases, as were mobile scenarios. AndyS suggested a public comment from Chris Wilper supports this requirement, as do limitations of JDBC drivers. RobS reported experience with a 3+ tier architecture where sorting and limits were handled outside the query system. RobS remained unconvinced that limit was essential. DanC raised the possibility of demoting it to an objective, but that was not supported by a critical mass, so we RESOLVED to adopt requirement "3.10 Result Limits" over the objection of RobS of Network Inference.

ACTION: SimonR draft a reply to Chris Wilper and send draft to WG mailing list.

Regarding 3.11 Iterative Query, the editor was advised to remove it until such time as more support becomes evident.

DanC noted that this exhausted the pending requirements and noted that WG members would need to generate some support for new requirements before they would be given time on group agendas.

Pending Objectives

Discussion of 4.1 Human-friendly Syntax resulted in support for addition of the word "easily", after which we RESOLVED to adopt objective 4.1 Human-friendly Syntax.

The group discussed objective "4.2 Provenance". About 5 known implementations were noted. EricP noted the importance of this feature for building trust in social systems, and KendallC noted the value to security applications. DanC asked if the research in KendallC's lab showed diverse designs or common patters; KendallC replied that there are a few different designs, but the most common one is quads. JosD asked if the URI sufficed as a provenance mechanism and KendallC answered positively.

RobS expressed a concern about defining provenance, that it might go beyond the scope of this group. DanC concurred; it seems to be at the edge of our scope.

AndyS clarified that the SOURCE mechanism in the BRQL spec is not about provenance; it's about data management; Jena supports "remove this model[i.e. graph]. replace with that model..."; a straightforward next step is to offer that to the user in the query language.

SimonR reported that while iTQL supports quads, it is not used very often, except for security applications.

A poll showed a continued critical mass of support, but not consensus. The chair did not put the question, since discussion continues to yield new arguments.

ACTION KendallC, AndyS: write up a new wording of 4.2 Provenance that focuses on data management.

Discussion of "4.3 Non-existent Triples" showed that "in the queried graph" would be a useful clarification. DanC estimated that this feature would be costly to specify; support remained above a critical mass, and we RESOLVED: "4.3 Non-existent Triples" accepted as a design objective; AndyS and Jos abstaining.

Discussion of "4.5 Aggregate Query" showed that various members of the group understood it to mean different things. ACTION SimonR: offer a replacement for 4.5 focussed on union query.

Discussion of "4.9 Boolean Results" suggested that it was overly detailed for a design objective. We RESOLVED to adopt as a design objective "yes/no questions should be straightforward to express", giving editor perhaps more than the usual license to exercise editorial judgement.

Proponents of "4.4 User-specifiable Serialization" were sufficiently confident that our design would satisfy them that they didn't need it explicitly in the document. ACTION Kendall: remove 4.4 User-specifiable Serialization

In discussion of "4.8 Literal Search", the editor asked if what we mean is really just string literals, and several answered yes. We RESOLVED to accept "4.8 Literal Search", clarified to refer to string literals, as a design objective, with EricP and RobS abstaining.

Initial Design Positions, revisited

DanC briefly introduced BRQL - A Query Language for RDF and observed that it seemed to be consistent with input from a critical mass of the working group regarding an initial strawman design, and polled the group for support. RobS and JeffP of Network Inference remained unconvinced that this was a useful direction.

Then we went to dinner, hosted by Network Inference.

New Use cases (ebXML registry, XQuery/RDF)

ACTION Hendler: work with Bijan to do some sort of UDDI/Web services use case. CONTINUES from 2004-06-29 telcon

We discussed ACTION: write up ebXML registry UC; there was considerable support for adding it. ACTION Kendall: add ebXML UC.

RobS noted that the use case discusses using stepwise query refinement to navigate a concept hierarchy, and that perhaps concept-hierarchy-browsing is a better technique in that case. ACTION: RobS write email to Farrukh.

JeffP reported that he participates, along with FarrukhN, in the OASIS regrep TC, which is adapting their registry information model specification (PDF) to use OWL. JeffP mailed the WG regarding some work in progress on ebXML RegRep draft OWL to RIM mapping.

EricP reported on some brainstorming on use cases relevant to section 1.5 Relationship to XQuery from the WG charter. An example of using RDF data in an XQuery system: querying the Edgar database and integrating XML and RDF sources into the one query.

DanC asked, regarding XQuery/RDF query integration scenarios: is loose coupling sufficient? is there motivation for anything more than string concatenation to make up queries, and XML to return results?

Discussion explored various approaches without any particular conclusion.

We then broke into two groups.

BRQL Walkthru break-out

In one break-out room, the group reviewed BRQL, with AndyS noting issues in the document (resulting in v1.11). Some members also took IRC notes starting 18:09:53Z.

ACTION Jos: explain log:includes to inform the discussion of SOURCE (nee provenance)

ACTION AndyS: explain DESCRIBE design implicit in BRQL spec.

ACTION DanC: explain evolution of log:semantics/log:includes from uri-is-graph to uri-is-doc in cwm, to inform discussion of SOURCE

ACTION DaveB: explain the main uses seen for redland contexts with respect to the provenance

DanC asked what test coverage do we have; AndyS reported that for RDQL, we have a test suite that is sufficiently complete to serve as a guide for independent developers. For other BRQL features, test development has only started; for example, a manifest of a few BRQL tests. ACTION Jos: discuss test suite documentation and maintenance with SteveH, EricP, AndyS, ...

XQuery design exploration

RobS, EricP, and SimonR explored XQuery designs in another break-out. When they returned, EricP briefly showed a report, including two examples:

Description	RDQL	XQuery
vcard	SELECT ?family , ?given WHERE (?vcard vcard:FN "Alice Antwerp") (?vcard vcard:N ?name) (?name vcard:Family ?family) (?name vcard:Given ?given) USING vcard FOR <http://www.w3.org/2001/vcard-rdf/3.0#>	DECLARE ELEMENT NAMESPACE vcard = <http://www.w3.org/2001/vcard-rdf/3.0#> FOR $vcard IN rdfNodes(), $name IN rdfNodes(), $family IN rdfNodes(), $given IN rdfNodes() WHERE asserted($vcard vcard:FN "Alice Antwerp"), AND asserted($vcard vcard:N $name), AND asserted($name vcard:Family $family), AND asserted($name vcard:Given $given) RETURN <p>$family $given</p>
selection on value	SELECT ?resource WHERE (?resource info:age ?age) AND ?age >= 24 USING info FOR <http://example.org/peopleInfo#>	DECLARE ELEMENT NAMESPACE info = <http://example.org/peopleInfo#> FOR $resource IN rdfNodes(), WHERE asserted($resource info:age $age) AND ?age >= 24 RETURN <foo>$resource</foo>

Description

RDQL

XQuery

vcard

SELECT ?family , ?given
WHERE  (?vcard  vcard:FN "Alice Antwerp")
       (?vcard  vcard:N  ?name)
       (?name   vcard:Family  ?family)
       (?name   vcard:Given  ?given)
USING  vcard FOR <http://www.w3.org/2001/vcard-rdf/3.0#>

DECLARE ELEMENT NAMESPACE vcard = <http://www.w3.org/2001/vcard-rdf/3.0#>
FOR $vcard IN rdfNodes(), 
    $name IN rdfNodes(), 
    $family IN rdfNodes(), 
    $given IN rdfNodes()
WHERE asserted($vcard  vcard:FN "Alice Antwerp"), 
  AND asserted($vcard  vcard:N  $name), 
  AND asserted($name   vcard:Family  $family), 
  AND asserted($name   vcard:Given  $given) 
RETURN <p>$family $given</p>

selection on value

SELECT ?resource
WHERE (?resource info:age ?age)
AND ?age >= 24
USING info FOR <http://example.org/peopleInfo#>

DECLARE ELEMENT NAMESPACE info = <http://example.org/peopleInfo#>
FOR $resource IN rdfNodes(), 
WHERE asserted($resource info:age $age)
  AND ?age >= 24
RETURN <foo>$resource</foo>

EricP and SimonR briefly presented an Abstract Model of Where Clause:

N is the set of RDF nodes.
$ is the set of variables.
Pos := N u $
C := Pos × Pos × Pos
Cexp := field(C, AND, OR) ... c1 AND c2 , c1 OR c2
B := $ × '=' × N
Bexp := field(B, AND, OR)
f(c ∈ C) -> b ∈ Bexp

Toward updated Use Cases and Requirements publication

DanC asked the editor for a publication target and KendallC suggested 1 August. We reviewed pending suggested changes:

RESOLVED: to adopt 4.X Addressable Query Results as proposed 15July as a design objective, SimonR abstaining.

We discussed Proposed XQuery requirement and/or objective without reaching critical mass around any particular wording. ACTION SimonR: write a document discussing tradeoffs with adapting XQuery as an RDF query language for discussion thru the September meeting in Bristol. Howard, among others, expressed interest in contributing.

Following up on various indications of support for a disjuction requirement, RobS offered New requirement: disjunction. After a poll showed a critical mass of support, we RESOLVED to adopt as a requirement "The query language must include the capability to restrict matches on a queried graph based on a disjunction of graph patterns, at least one of which must be satisfied.", JosD abstaining. ACTION RobS: help the editor find supporting use cases for disjuction.

ACTION KendallC: draft revision, toward updating our public WD, delivery ~next wed. ACTION RobS: review it. ACTION Howard: to offer editorial feedback.

Initial Design/Strawman query language

DanC suggested that the lack of critical mass of support around any particular XQuery-related objective, requirement, or design at this point merited the attention of the Semantic Web Coordination Group. ACTION DanC: notify Semantic Web CG of risks around the "1.5 Relationship with XQuery" scope of our charter.

Candidates with a critical mass of support appear to be RDQL of 9 Jan 2004 and BRQL v1.11. DanC advised the WG that starting with fewer, more mature features was likely to help us go faster, but a poll showed more support for BRQL than RDQL.

DanC observed that while we do not have consensus, we do have a critical mass off support for BRQL, and discussion of alternatives at this point does not seem to yield new arguments; further, selection of a strawman at this point is important in order to stay on schedule. We RESOLVED to adopt BRQL v1.11 as our strawman query language design, over the objection of RobS and JeffP of Network Inference and HowardK's abstention.

A brief review yielded a few more issues:

NEW ISSUE: re CONSTRUCT: what happens when variable are not bound?

NEW ISSUE: BRQL 1.11 does not support yes/no queries sufficiently

YoshioF asked if we're going to have other strawmen, and DanC noted that SimonR's action means we plan to discuss at least one other.

Exploration of protocol designs

We explored a few protocol designs: GetData from the TAP project, Joseki, cwm's definitiveService, and Tucana's RMI experience. Notes from IRC starting 23:38:08Z and continuing 16Jul(UTC) have some details

We RESOLVED to thank the host, Network Inference, with applause, and adjourned the meeting.

RDF Data Access Working Group Meeting, July 2004

hosted in Carlsbad, California by Network Inference

Agenda

Wed, 14 Jul

Thu, 15 Jul

Venue

Participants