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

Fair - in which case we need to tie both "open" and "closed" validation back to motivating use cases. Currently, I think they only offer a "closed" validation case. 

-----Original Message-----
From: David Booth [mailto:david@dbooth.org] 
Sent: 07 April 2014 14:19
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"

The downside of bundling them together is that it presupposes a solution that will enable that optionality in metadata.  By splitting the requirement into two requirements, the WG can more easily decide which of the individual requirements (either, both or neither) to meet.

David

On 04/07/2014 09:10 AM, Tandy, Jeremy wrote:
> 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-u
>> c
>>
>>
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:21:44 UTC