W3C home > Mailing lists > Public > public-csv-wg@w3.org > February 2014

Re: Scoping Question

From: Eric Stephan <ericphb@gmail.com>
Date: Sat, 22 Feb 2014 05:51:16 -0800
Message-ID: <CAMFz4jhMC0HEwvhXZxpobkJOcB-RJGKxDMXfpOO+V7iuoh-0RA@mail.gmail.com>
To: Jeni Tennison <jeni@jenitennison.com>
Cc: "public-csv-wg@w3.org" <public-csv-wg@w3.org>
If we choose APPROACH 1 we effect existing well established data
communities who already publish/store CSV documents on the web and
helping to make them 5 Star by introducing metadata in an innovative

If we choose APPROACH 2 we effect new "Data" communities who publish
little or are reluctant to use the web for their CSV data.  If we do
this I suggest we conduct surveys to document these anticipated user
community.  I'm not saying existing communities might not switch to
the new approach, but from a scientific perspective, these users are
going to trust their own domain communities and familiar tools as
opposed to switching to a new approach.

If I have to vote +1 I choose APPROACH 1 only because I am more
familiar with the impact our group could have helping make CSV data
more findable and useful on the web.

Eric Stephan

On Fri, Feb 21, 2014 at 8:31 AM, Jeni Tennison <jeni@jenitennison.com> wrote:
> Hi,
> [Only just got net connection to enable me to send this.]
> A scoping question occurred to me during the call on Wednesday.
> There seem to be two approaches that we should explicitly choose between.
> APPROACH 1: Work with what's there
> We are trying to create a description / metadata format that would enable us to layer processing semantics over the top of all the various forms of tabular data that people publish so that it can be interpreted in a standard way.
> We need to do a survey of what tabular data exists in its various formats so that we know what the description / metadata format needs to describe. When we find data that uses different separators, pads out the actual data using empty rows and columns, incorporates two or more tables inside a single CSV file, or uses Excel spreadsheets or DSPL packages or SDF packages or NetCDF or the various other formats that people have invented, we need to keep note of these so that whatever solution and processors we create will work with these files.
> APPROACH 2: Invent something new
> We are trying to create a new format that would enable publishers to publish tabular data in a more regular way while preserving the same meaning, to make it easier for consumers of that data.
> We need to do a survey of what tabular data exists so that we can see what publishers are trying to say with their data, but the format that they are currently publishing that data in is irrelevant because we are going to invent a new format. When we find data that includes metadata about tables and cells, or groups or has cross references between tables, or has columns whose values are of different types, we need to keep note of these so that we ensure the format we create can capture that meaning.
> We also need to understand existing data so that we have a good backwards compatibility story: it would be useful if the format we invent can be used with existing tools, and if existing data didn't have to be changed very much to put it into the new format. But there will certainly be files that do have to be changed, and sometimes substantially.
> My focus is definitely on the second approach as I think taking the first approach is an endless and impossible task. But some recent mails and discussion has made me think that some people are taking the first approach. Any thoughts?
> Cheers,
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com/
Received on Saturday, 22 February 2014 13:51:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:38 UTC