Per section 6 Working Groups, Interest Groups, and Coordination Groups of the W3C Process, this charter, and any changes to it, take effect by way of an announcement to the W3C Membership via w3c-ac-members.
W3C published the initial RDF Model and Syntax Specification in 1999. Use of RDF data has lead to the development of several RDF Query languages. It is hoped that a recommended query language will reduce redundancy and enhance interoperability as SQL did for relational databases. This document defines a two-part charter for the RDF Data Access Working Group. In the first phase, the WG will evaluate requirements and select a strawman RDF query language, or document why divergent requirements make this impossible. If a strawman is selected, the WG will enter the second phase in which it will write a formal specification and test cases for this language.
The RDF data model is a directed, labeled graph with edges labeled with URIs and nodes that are either unidentified, literals, or URIs (please see the RDF Primer for further explanation). The principal task of the RDF Data Access Working Group is to gather requirements and to define an HTTP and/or SOAP-based protocol for selecting instances of subgraphs from an RDF graph. The group's attention is drawn to the RDF Net API submission. This will involve a language for the query and the use of RDF in some serialization for the returned results. The query langauge may have aspects of a path language similar to XPath (used for XML in XSLT and XQuery) and various RDF experimental path syntaxes.
The working group will review existing applications and query language implementations. It will document the requirements for an RDF query language and data access protocol.
The requirements document will assist in the selection of a strawman query language. The working group will evaluate expressivity needs and other constraints gathered during the requirements phase and select a starting point for design from a list of existing query langauges (eg RDQL, XQuery, RuleML, N3). This query language is to be used as a starting point for phase 2. If the working group is unable to select a query language that meets, or can meet, the requirements, it will document the reasons this is not possible and either adjourn or ask the Advisory Committee to re-charter the working group.
This completes phase 1 of the working group charter. If a strawman is selected, the working group will continue with phase 2 without further review by the Advisory Committee.
Specification of an abstract syntax promotes interoperability between alternate serializations and APIs. It also helps illustrate the commonalities and differences with other query languages. The working group will produce an abstract syntax for the query language and protocol.
The working group must bind the abstract syntax to a concrete syntax. This syntax may resemble the syntax of the strawman query language, but that is not in any way required.
At this stage, it is not clear to what extent XQuery technology is applicable to the task of querying RDF datasets. The RDF DAWG should aim to maximize W3C technology re-use, while also taking account of differences between the RDF graph data model and the XQuery data model.
There is a requirement for RDF data to be accessable within an XML Query context. The working group should specify at least one mechanism for exposing RDF query facilities in an XQuery environment; that is, a way to take a piece of RDF Query abstract syntax and map it into a piece of XML Query using some form of extension to XQuery. The working group should examine TreeHugger and XQuery with Functional Accessors in their discussion of the use of XQuery with RDF.
While the data model of the query language of this protocol is dissimilar to that of XQuery, a non-XML concrete syntax might reuse syntactic elements from XQuery to aid learning time, even if XQuery is not chosen as the strawman.
Many items ruled out of scope by this charter require an extensibility mechanism for later implementation. This mechanism must allow for arbitrary combinations of orthogonal extensions.
The working group will need to make trade-offs in accepting query requirements that are practical for use in general semantic web applications while maintaining a simple, easy to implement query mechanism. Many of these trade-offs will affect expressivity, eg disjunction, negation (of various forms), optional relations or node identification. The Requirements Document and test cases will provide the working group with guidance in making these trade-ffs.
The working group must recognize that RDF graphs are often constructed by aggregation from multiple sources and through logical inference, and that sometimes the graphs are never materialized. Such graphs may be arbitrarily large or infinite.
The protocol will allow access to a notional RDF graph. This may in practice be the virtual graph which would follow from some form of inference from a stored graph. This does not affect the data access protocol, but may affect the description of the data access service. For example, if OWL DL semantics are supported by a service, that may be evident in the description of the service or the virtual graph which is queried, but it will not affect the protocol designed under this charter.
While it is hoped that the product of the RDF Data Access Working Group will be useful in later development of a rules language, development of such a rules language is out of scope for this working group. However, any serializations of a query language must not preclude extension to, or inclusion in, a rules language. The group should expend minimal effort assuring that such an extension be intuitive and and consistent with any query language produced by the group.
Some languages, for instance, OQL, define a layer of protocol that handles requester/server interactions for result set cursors or proofs. The abstract syntax may be extensible to express the relevant parameters, but their definition and effects are beyond the scope of this working group.
Some existing protocols, such as the RDF Net API, define operations for changing a graph. The RDF Data Access Working Group is only required to defined a protocol for conveying queries and their results. However, the group should be aware that it is likely that their work will be extended to support modifying the graph and should expend reasonable effort to ensure that such extension is easy, moreover, the group may include such an ability.
This schedule represents an initial plan. As more information becomes available, milestones may be renegotiated with the Semantic Web Coordination Group. Schedule changes that impact resource allocations are charter changes that require Advisory Committee review.
Coordination with other groups will be managed through the Semantic Web Coordination Group.
W3C has 3 recommendations in the area of selecting from XML infosets: XPath, XQuery and XSLT. While RDF query addresses a different data domain (the RDF graph), any query mechanisms defined by this group must leverage off, and, where possible, interoperate with, the related XML recommendations.
Proper layering of RDF languages is crucial to the integrity of the Semantic Web. Each deliverable of any Working Group must satisfy the dependencies from other W3C Working Groups before it can advance to Candidate Recommendation.
The RDF Core and WebOnt working groups' charters are expected to expire before the DAWG publishes its first working draft. The Semantic Web Best Practices and Deployment (SWBPD) Working Group will be meeting when these groups terminate so the DAWG will seek its architectural review.
The RDF Data Access WG and the Internationalization Working Group will work together to clarify and resolve internationalization and localization issues in XML Schema, and will jointly ensure that it satisfies W3C goals for international access to the Web.
The group's attention is drawn to the fact that many Internet protocols involve data access, for example LDAP, IMAP, WebDAV. It is not intended that the data access protocol perform tasks for which these protocols were designed. However, they may provide a source of instructive use cases.
To become a member of the RDF Data Access Working Group, a representative of a W3C Member organization must be nominated by their Advisory Committee Representative. The appropriate process will be identified in the Call for Participation.
Each W3C Member organization is limited to at most one principal participant and one alternate participant of this Working Group. Attendance by an alternate discharges the principal's attendance obligations.
Participation is also open to invited experts from the community, selected by the chair, in accordance with the Invited Experts provisions in the Process Document, in order to balance the technical experience of the group. Invited experts participate as principals.
Participation is expected to consume at least one day per week of each Working Group participant's time.
The Working Group's technical discussions will occur on the public mailing list public-rdf-dawg. All technical documents and decisions will be made available to the public through the Working Group's process.
The Working Group will use a home page to record the history of the group, and which will provide access to the archives, meeting minutes, updated schedule of deliverables, membership list, and relevant documents and resources. The page will be available to the public and will be maintained by the Chair in collaboration with the W3C team contact. This page will be linked from the RDF home page.
A one to two hour Working Group phone conference will be held every week. When necessary to meet agreed-upon deadlines, phone conferences may be held twice a week. Each principal (or alternate) participant is expected to participate in phone conferences. The Chair may, at his or her discretion, invite guest experts to attend particular phone conferences.
Meeting records should be made available within three days of each telephone meeting. Meeting records must be made publicly available except for non-technical issues that do not directly affect the output of the Working Group. The Chair decides which issues are not made public.
Participation in face-to-face meetings is limited to working group members and observers invited by the Chair. Decisions may be taken in face-to-face meetings but must be announced on the Working Group mailing list. Observers may take part in decision-making at the discretion of the Chair.
In addition to the required face-to-face meetings, the Working Group may schedule other face-to-face meetings in a manner that maximizes co-location with events that Working Group members would be attending anyway.
The Chair makes Working Group meeting dates and locations available to the group at least eight weeks before the meeting, per W3C Process.
To be successful, we expect the Working Group to have approximately 10 to 15 participating Member organizations and invited experts for its duration. We also expect a large public review group that will participate in the mailing list discussions.
The W3C Team expects to dedicate the services of one engineer at 40% for the duration of the Working Group.
This Working Group operates under the W3C Patent Policy (5 Feb 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. The inclusion of the new Patent Policy in the charter is contingent upon successful completion of AC review of the Process Document and Patent Policy Transition Procedure.