RDF Data Access WG Charter (original) (raw)
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.
Table of Contents
- Scope of RDF Data Access Working Group
- Out of Scope
- Schedule
- Relationship with Other W3C Activities
- Participation, Meetings, and Logistics
1. Scope of RDF Data Access Working Group
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.
1.1 Query Language and Protocol Requirements Document
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.
1.2 Strawman Query Language Section
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.
1.3 Abstract Syntax
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.
1.4 Concrete Syntax
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.
1.5 Relationship with XQuery
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.
1.6 Extensibility Mechanism
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.
1.7 Defined Expressivity
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.
1.8 Derived Graphs
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.
2. Out of Scope
2.1 Specification of RDF Schema/OWL semantics
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.
2.2 RDF Rules
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.
2.3 Cursors and proofs
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.
2.4 Graph Update Protocol
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.
3. Schedule
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.
Feb 2004 - Group Formation
W3C Members with relevant interest and expertise join the working group. The chair may elect to invite non-W3C experts.
April 2004 Face to Face Meeting to Consider Use Cases and Requirements
The RDF Data Access Working Group will discuss use cases and evaluate the requirements. The group should pick an existing query language or draft a straw-man. This language will allow the Working Group to begin developing test materials. Throughout development, the working group will maintain test cases to reflect issue resolution and aid in conformance evaluation.
June 2004
2nd face to face meeting
September 2004 Publish Working Draft of Design (1)
September/October - Third Face to Face
The working group will discuss progress in resolving issues.
November - Publish Working Draft (2)
December - Fourth Face to Face (if necessary)
If the group decides there are sufficient outstanding issues, they will have a face to face meeting to resolve them before the Last Call Working Draft.
January 2005 - Publish Last Call Working Draft (3)
(March - Candidate Recommendation if necessary)
June - Proposed Recommendation
July - Recommendation
July - October - Errata/Wrap-up
November 2005 - January 2006 - Three-month contingency period
The above schedule allows for an estimated three working drafts developed in two months each. This contingency period may be used if additional time is required.
4. Relationship with Other W3C Activities
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.
The XPath language defines a non-XML syntax for addressing subtrees from XML documents. It factors out the selection functionality common to XQuery and XSLT. It is hoped that RDF Query will provide analogous functionality for addressing subgraphs. The working group will adopt, or define relationships with, applicable portions of the XPath data model.
The Relationship to XQuery section defines the interactions with XQuery.
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.
RDF Core Working Group
While each charted RDF working group is responsible for the soundness of the interactions between their product and other RDF-related work, the RDF Core Working Group is in a unique position to provide oversee this process. The RDF Core is responsible for the RDF data model. The RDF Data Access Working Group must provide a query mechanism for selecting data from this model or document to the RDF Core Working Group's satisfaction the impracticality/impossibility of doing so.
OWL Working Group
OWL provides a set of terms and semantics that must be queryable by the product of the RDF Data Access Working Group. As stated above, the ability of a data store to perform inferences is outside the scope of this group.
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.
4.1 Internationalization
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.
4.2 Reference work
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.
5. Participation, Meetings, and Logistics
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 oneprincipal 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.
5.1 Email Communication
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.
5.2 Group Home Page
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.
5.3 Telephone Meetings
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.
5.4 Face-to-Face Meetings
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.
5.5 Resources
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.
5.6 W3C Team Involvement
The W3C Team expects to dedicate the services of one engineer at 40% for the duration of the Working Group.
5.7 Intellectual Property Rights
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.
Eric Prud'hommeaux <eric+rdfq@w3.org>
$Id: dawg-charter.html,v 1.23 2021/11/15 09:01:26 eric Exp $