RDF Literal Direction Working Group Charter

The mission of the RDF Literal Direction Working Group is to add base direction metadata to RDF language tagged literals.

Join the Working Group.

Start date 01 October 2019
End date 31 December 2020 or 1 September 2020
Chairs [chair name] (affiliation)
Team Contacts Ivan Herman (0.1 FTE)
Meeting Schedule Teleconferences: 1-hour calls will be held weekly.
Face-to-face: we may meet during the W3C's annual Technical Plenary week; no extra face-to-face meetings are planned.

Scope

There is a problem at the intersection of RDF Literals and internationalization. When using string Literals for natural language texts, the langString datatype of RDF 1.1 provides the possibility to add the language information via a bcp47 language tag. However, it is not possible to express the base text direction (i.e., right-to-left or left-to-right) of the same literal. While this issue is solved in HTML through the dir attribute, and can be done when defining, e.g., a set of terms in simple JSON, this is not possible in the abstract model of RDF and, consequently, in the serialization syntaxes of RDF like Turtle or JSON-LD. See a separate document, and the corresponding github issues, for a more detailed description of the problem as well as the possible solutions that have been explored.

This Working Group will update the RDF 1.1 family of specification (including the serializations syntaxes), as well as adapt a number of other, related specifications to include a base direction information for the langString datatype (see a detailed list of specifications below). These changes must be backward compatible, i.e.,

Official editorial errata for the specifications in the respective families of documents will also be handled by the Working Group (see the references to the official errata lists in the section on deliverables). In case of doubt, the original errata author(s), as well as appropriate experts, must be contacted to make sure that the changes are not technical.

Out of Scope

  • Any other technical improvements or changes on the documents listed in the list of specifications below.
  • Changes on the OWL family of specification.

Success Criteria

In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations regarding the base direction defined on language tagged Literals, when applicable (i.e., if the new specifications differ from the previous versions in more than just editorial changes).

Each specification should contain a section detailing all known security and privacy implications for implementers, Web authors, and end users.

There should be testing plans for each specification, starting from the earliest drafts.

Deliverables

More detailed milestones and updated publication schedules are available on the group publication status page.

The list below uses “RDF 1.2” or “RDFa 1.2”, etc., to designate the new releases; this should be considered as indicative only. It will be the decision of the Working Group to choose the final version numbers.

Normative Specifications

The Working Group will deliver the following updated specifications referring to the new version of the langString datatype (when applicable) and with possible editorial errata changed:

Deliverables for the “Integral update” alternative
RDF 1.2
This term refers to a family of documents, published in 2014. The current list comprises:

See also errata.

RDFa 1.2
This term refers to a family of documents, published in 2015. The current list comprises:

See also errata.

SPARQL 1.2
This term refers to a family of documents, published in 2013. The current list comprises:

See also errata.

SHACL 1.1
This term refers one document, published in 2017:

See also errata.

CSVW 1.1
This term refers to a family of documents, published in 2015. The current list comprises:

See also errata.

RDB2RDF 1.1
This term refers to a family of documents, published in 2015. The current list comprises:

See also errata.

Deliverables for the “Hybrid” alternative
RDF Datatype for Language Literals

This specification defines one or more RDF datatypes to represent language literals with an optional base direction.

RDF 1.2
This term refers to a family of documents, published in 2014. The current list comprises:

See also errata.

RDFa 1.2
This term refers to a family of documents, published in 2015. The current list comprises:

See also errata.

Note: most of the current specifications may not need to change (i.e., there are no editorial errata, and the addition of the base direction to a literal does not affect the technical content). They should nevertheless be republished to be in line, editorially, with the right version names and cross references, with the updated specifications.

Other Deliverables

Other non-normative documents may be created such as:

  • Use case and requirement documents;
  • Test suite and implementation report for the specification;
  • Primer or Best Practice documents to support web developers when designing applications.

Timeline

Timeline for the “Integral update” alternative
Timeline for the “Hybrid” alternative
  • October 2019: First teleconference
  • November 2019: FPWD for all the specifications listed above
  • January 2020: CR for all the specifications listed above
  • June 2020: PR for RDF 1.2 and RDFa 1.2
  • August 2020: Rec for RDF 1.2 and RDFa 1.2

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD and at least 3 months before CR, and should be issued when major changes occur in a specification.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

W3C Groups

JSON-LD Working Group
to synchronize on the exact serialization of the new RDF feature in JSON-LD
Internationalization Working Group
to ensure that the new features are correct from an Internationalization point of view and cover all the missing features in the previous version of RDF

Participation

To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the (Working|Interest) Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the RDF Literal Direction Working Group home page.

Most RDF Literal Direction Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its technical work on the public mailing list public-[email-list]@w3.org (archive) and on GitHub issues. The public is invited to review, discuss and contribute to this work.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 5 February 2004 updated 1 August 2017). 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. For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.