CSV on the Web Working Group Charter

Scope

Tabular data has many usage scenarios. It is often used directly, without any manipulation of the data. For example, CSV content may be extremely large and its conversion might be unnecessarily time-consuming; or its usage is restricted to the data itself without the necessity to integrate with other datasets (a typical example may be the medical prescription data that a hospital or a national health service publishes on the Web and an application that only publishes the results of an analysis of the data). In other cases, the CSV content must be converted to other data formats to be used with data sources of a different origin, or with the application developer’s specific tools.

Whether converted to other formats or not, there is a need to describe the content of the CSV file: its structure, datatypes used in a specific column, language used for text fields, access rights, provenance, etc. This means that metadata should be available for the dataset, relying on standard vocabulary terms, and giving the necessary information for applications. The metadata can also be used for the conversion of the CSV content to other formats like RDF or JSON, it can enable automated loading of the data as objects, or it can provide additional information that search engines may use to gain a better understanding of the content of the data. It should also be possible to encode this metadata in RDF, thereby providing a “glue” to bind the CSV content to other datasets in different formats and to Linked Data in general. In this way CSV datasets become linkable on the Web via the metadata, even if the content remains in its original tabular format.

While the primary focus of this WG is on associating metadata with CSV files, to the extent possible the WG should consider and favor design choices that make the vocabulary useful with other tabular structured data use cases and in particular HTML tables.

To provide the necessary infrastructure for CSV on the Web, the Working Group will develop the following building blocks:

1. A metadata vocabulary describing the content of tabular data, like row and column structure, headings, datatypes, etc. A careful consideration of common use cases should generate the set of requirements that the metadata vocabulary should fulfill. The vocabulary should be defined, or should have an encoding, in standard RDF and, wherever possible and appropriate, should refer to, and reuse, existing vocabularies developed elsewhere.
2. Standard method(s) to find the metadata for a specific dataset. Several approaches should be explored and possibly specified: possibilities include the inclusion of a metadata reference in the HTTP header for the dataset’s URI; the extension of the CSV structure with special rows and/or columns containing the metadata or a URI pointing at the metadata; or the definition of a standard packaging format containing the CSV data as well as its metadata. The Working Group will explore these different possibilities, cross-check them with use cases, and recommend one or more mechanisms.
3. Standard method(s) to find the data described by the metadata. Closely allied to the previous point, the working group will define a simple link mechanism from the metadata to the data. Metadata may be created alongside the data it describes or completely independently by a third party. Either way, such a link may of course dereference to a static file or it may encode a query for a service available on the Web, such as an OData service or other API. Definition of the structure of those links/queries is out of scope.
4. Standard mapping mechanisms transforming CSV to other formats (e.g., RDF, JSON, or XML). 

Notes:

This charter refers to “CSV”, i.e., “Comma Separated Values”; a similar, though less frequently used format is ”TSV”, for “Tab Separated Values”. All the specifications developed for CSV can be adapted to TSV easily; the Working Group may decide to take the TSV format into account, too, when formalizing the technologies.)

The term “mapping mechanism” does not necessarily mean a physical conversion of the data to another format; it may mean providing an, e.g., RDF “view” of the tabular data provided by a specialized server-side application.)

The XForms 2.0 draft specification includes the definition of XPath expressions for CSV; the Working Group will consider whether this fulfills the for an XML requirements or whether a separate specification is indeed necessary.

The output of the mapping mechanism for RDF MUST be consistent with either the RDF Direct Mapping or R2RML so that if a table from a relational database is exported as CSV and then mapped it produces semantically identical data.

Although not specified by W3C, the Working Group should also contribute to a newer version of RFC 4180 to ensure a better interoperability of CSV content. An example is the current restriction in the RFC to use ASCII only, which is inappropriate from the point of view of proper Internationalization on the Web and is not in line with the practice of CSV deployment.

Input documents

The following documents may be considered by this Working Group:

Non W3C documents

• Linked CSV, Unofficial Draft, ODI (2013), J. Tennison, (ed.)
• Common Format and MIME Type for Comma-Separated Values (CSV) Files, RFC 4180, The Internet Society (2005), Y. Shafranovich, (ed.)
• A JSON Media Type for Describing the Structure and Meaning of JSON Documents, Draft, The Internet Society (2011), K. Syp, G. Court, (eds.)
• URI Fragment Identifiers for the text/csv Media Type, Draft, The Internet Society (2013), M. Hausenblas, E. Wilde, and J. Tennison (eds.)
• Simple Data Format (SDF), Draft, OKFN Labs, (2013), R. Pollock (ed.)
• Dataset Publishing Language, Draft, Google Developers, (2013), O. Benjelloun (ed.)
• CSV Meta Description, Draft, Talis (2011), A. Dix (ed.)
• CSV2RDF Application (Ivan Ermilov, Sören Auer, Claus Stadler)
• TARQL Mapping Language (Richard Cyganiak)
• GREL Functions
• OData Version 4.0 Part 1: Protocol (Michael Pizzo, Ralf Handl, Martin Zurmuehl)

W3C documents

• PROV-AQ: Provenance Access and Query, W3C Working Group Note, (2013), G. Klyne and P. Groth (eds.)
• The RDF Data Cube Vocabulary, W3C Draft, (2013), R. Cyganiak and D. Reynolds (eds.)
• SPARQL 1.1 Query Results CSV and TSV Formats, W3C Recommendation, (2013), A. Seaborne (ed.)
• R2RML RDB to RDF Mapping Language, W3C Recommendation, (2012), S. Das, S. Sundara, and R. Cyganiak (eds.)
• A Direct Mapping of Relational Data to RDF, W3C Recommendation, (2012), M. Arenas, A. Bertails, E. Prud’hommeaux, and J. Sequeda (eds.)
• Indexed Database API, W3C Candidate Recommendation, (2013), N. Mehta, J. Sicking, E. Graff, A. Popescu, J. Orlow, J.

Success Criteria

To advance to Proposed Recommendation, the metadata vocabulary should be shown to be used by at least two independent applications; “use” may also mean extended to other, more specialized vocabularies.

To advance to Proposed Recommendation, each conversion specification is expected to have at least two independent implementations of each feature defined in the specification. Similarly, each mechanism for the discovery of metadata should be implemented by at least two independent implementations.

During its lifetime the group has to produce enough outreach material so that the community at large is actively encouraged to use the technologies defined by the Working Group. It is expected that implementations will include parsers/importers for NoSQL databases such as MongoDB, as well as SQL databases, and triplestores. Exporters and converters should also be implemented from those same databases and from spreadsheet software. Validators, visualizers and other generic tooling is also foreseen since these tools are at the heart of the open data movement.