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

RE: ISSUE-8 of "Model for Tabular Data and Metadata on the Web"

From: Tandy, Jeremy <jeremy.tandy@metoffice.gov.uk>
Date: Mon, 7 Apr 2014 13:10:49 +0000
To: David Booth <david@dbooth.org>, "public-csv-wg@w3.org" <public-csv-wg@w3.org>, Jeni Tennison <jeni@jenitennison.com>, "'Gregg Kellogg'" <gregg@greggkellogg.com>
Message-ID: <2624871D9A05174691BD59F8EFD68AE208834A6C@EXXCMPD1DAG3.cmpd1.metoffice.gov.uk>
Good points ... rather than introducing a new requirement into the document, I propose that we capture both "open" and "closed" validation modes within R-CsvValidation. I like the idea of being able to drive both behaviours from the validation activity.

Jeremy

-----Original Message-----
From: David Booth [mailto:david@dbooth.org] 
Sent: 07 April 2014 14:07
To: Tandy, Jeremy; public-csv-wg@w3.org; Jeni Tennison; 'Gregg Kellogg'
Subject: Re: ISSUE-8 of "Model for Tabular Data and Metadata on the Web"

Hi Jeremy,

It sounds like the R-CsvValidation requirement may need to be split into two separate validation requirements:

R-CsvOpenValidation:
   Does the data in the CSV conform to the metadata, ignoring inapplicable metadata?  For example, is every column in the CSV described by some metadata?

R-CsvClosedValidation:
   Does the metadata describe anything that does NOT appear in the CSV?

I suppose if the metadata had a notion of optional columns then both of these cases could be covered at once.

David

On 04/07/2014 08:25 AM, Tandy, Jeremy wrote:
>> if a column is renamed from "City" to "Town", it could safely contain 
>> metadata for both City and Town columns, and whichever one did not 
>> appear in the CSV data would be ignored
>
> In Requirement
> R-CsvValidation<http://w3c.github.io/csvw/publishing-snapshots/FPWD-uc
> r/Overview.html#R-CsvValidation> we talked about being able verify 
> that a particular CSV file follows the data definition resource. So if 
> "City" or "Town" were missing, this would fail validation. We are yet 
> to progress onto what it means to validate a CSV file (over and above 
> checking it's well formed
> (R-WellFormedCsvCheck<http://w3c.github.io/csvw/publishing-snapshots/F
> PWD-ucr/Overview.html#R-WellFormedCsvCheck>)
> ...
>
> Jeremy
>
> PS. I note that in this iteration of the Use Case and Requirements 
> document, the level of detail in the Requirements is insufficient ...
> a reader needs to refer to the motivating use case to figure out the 
> details. We'll need to remedy this for later releases.
>
> -----Original Message----- From: David Booth [mailto:david@dbooth.org] 
> Sent: 07 April 2014 03:26 To:
> public-csv-wg@w3.org; Jeni Tennison; 'Gregg Kellogg' Subject: ISSUE-8 
> of "Model for Tabular Data and Metadata on the Web"
>
> Regarding ISSUE-8: http://w3c.github.io/csvw/syntax/#h_issue_8 [[ 
> Should there be a default navigational thing of continuing up the path 
> hierarchy until you find a metadata document? ]]
>
> My sense at present: No.  I suspect that would be substantially more 
> likely to lead to erroneous metadata interpretation than to be useful. 
> However, I *do* think it would be *very* useful to be able to put a 
> single metadata file in a directory and have it apply to all CSV files 
> in that directory.  This would be particularly useful to organizations 
> that periodically publish new versions of CSV files:
> the metadata file can be created once, and thereafter left unchanged 
> as new CSV files are added, at least until the structure or meaning of 
> the CSV file changes.
>
> BTW, to facilitate backward compatibility of metadata files, it would 
> be really nice if any non-applicable metadata were ignored.  So, for 
> example, if a column is renamed from "City" to "Town", it could safely 
> contain metadata for both City and Town columns, and whichever
> one did not appear in the CSV data would be ignored.   Was the WG
> already planning on this approach?
>
> Thanks, David
>
>
>
>
Received on Monday, 7 April 2014 13:11:16 UTC

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