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.
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.,
- all RDF 1.1 Graphs, containing triples with language tags literals, remain valid and with the same semantics;
- all SPARQL 1.1 queries involving RDF 1.1 graphs will return the same query results;
- all HTML and XML files with RDFa 1.1 markup will produce identical RDF Graphs.
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:
- RDF 1.1 Concepts and Abstract Syntax
- RDF 1.1 Semantics
- RDF Schema 1.1
- RDF 1.1 Turtle
- RDF 1.1 TriG
- RDF 1.1 N-Triples
- RDF 1.1 N-Quads
- RDF 1.2 XML Syntax
See also errata.
- RDFa 1.2
-
This term refers to a family of documents, published in 2015. The current list comprises:
- RDFa Core 1.1 - Third Edition
- HTML+RDFa 1.1 - Second Edition
- XHTML+RDFa 1.1 - Third Edition
- RDFa Lite 1.1 - Second Edition
See also errata.
- SPARQL 1.2
-
This term refers to a family of documents, published in 2013. The current list comprises:
- SPARQL 1.1 Overview
- SPARQL 1.1 Query Language
- SPARQL 1.1 Update
- SPARQL 1.1 Service Description
- SPARQL 1.1 Federated Query
- SPARQL 1.1 Query Results JSON Format
- SPARQL 1.1 Query Results CSV and TSV Formats
- SPARQL Query Results XML Format (Second Edition)
- SPARQL 1.1 Entailment Regimes
- SPARQL 1.1 Entailment Regimes
- SPARQL 1.1 Protocol
- SPARQL 1.1 Graph Store HTTP Protocol
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:
- Model for Tabular Data and Metadata on the Web
- Metadata Vocabulary for Tabular Data
- Generating JSON from Tabular Data on the Web
- Generating RDF from Tabular Data on the Web,
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:
- RDF 1.1 Concepts and Abstract Syntax
- RDF 1.1 Semantics
- RDF Schema 1.1
- RDF 1.1 Turtle
- RDF 1.1 TriG
- RDF 1.1 N-Triples
- RDF 1.1 N-Quads
- RDF 1.2 XML Syntax
See also errata.
- RDFa 1.2
-
This term refers to a family of documents, published in 2015. The current list comprises:
- RDFa Core 1.1 - Third Edition
- HTML+RDFa 1.1 - Second Edition
- XHTML+RDFa 1.1 - Third Edition
- RDFa Lite 1.1 - Second Edition
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
- October 2019: First teleconference
- November 2019: FPWD for all the specifications listed for RDF 1.2 and RDFa 1.2
- January 2020: CR for RDF 1.2 and RDFa 1.2
- March 2020: FPWD for the specifications listed above, except for RDF 1.2 and RDFa 1.2
- May 2020: CR for the specifications listed above, except for RDF 1.2 and RDFa 1.2
- June 2020: PR for RDF 1.2 and RDFa 1.2
- August 2020: Rec for RDF 1.2 and RDFa 1.2
- October 2020: PR for the specifications listed above, except for RDF 1.2 and RDFa 1.2
- December 2020: Rec for the specifications listed above, except 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.