Re: Data Package RFCs coming up ...

On 3 July 2015 at 12:22, Ivan Herman <ivan@w3.org> wrote:
>
>> On 03 Jul 2015, at 13:16 , Rufus Pollock <rufus.pollock@okfn.org> wrote:
>>
>> On 3 July 2015 at 12:09, Ivan Herman <ivan@w3.org> wrote:
>>
>> > On 02 Jul 2015, at 21:21 , Gregg Kellogg <gregg@greggkellogg.net> wrote:
>> >
>> >> On Jul 2, 2015, at 5:02 AM, Rufus Pollock <rufus.pollock@okfn.org> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> I wanted to flag that the Data Package suite of "proposals" which includes:
>> >>
>> >> - Data Package - http://dataprotocols.org/data-package/
>> >> - JSON Table Schema - http://dataprotocols.org/json-table-schema/
>> >> - Tabular Data Package - http://dataprotocols.org/tabular-data-package/
>> >>
>> >> Are being readied for submission as IETF RFC's.
>> >>
>> >> Folks on this list are no doubt very familiar with these as they formed a basis for the initial CSV spec here (especially tabular data package).
>> >>
>> >> We have long planned to do this and have been waiting for the specs to mature - especially actual implementations to exist - to submit as proper RFCs and over the last year or so we've felt we're nearing that point and so this should happen very soon.
>> >>
>> >> I wanted to flag now especially if there were any specific alignment that could be done that would be great to do now - i know I have flagged some issues on the dataprotocols tracker over the last year on this.
>> >
>> > Couple of things I noted looking through:
>> >
>> > * The Dialect Description Format is similar to, but not the same as our dialect description. In addition to the version property (csvddfVersion), you have a caseSensitiveHeader, which CSVM lacks.
>> > * The data package calls for a descriptor named datapackage.json, which references a JSON descriptor which seems functionally equivalent to ours, but different. Were they to converge, this could be a reason to use the .well-known/csvm to identify it were it not contained within a package; adding .well-known/csvm with “/databackage.json” as the only pattern would be consistent with how we define lookup.
>> > * Many of the properties included in the datapackage, if namespaced, would work fine as common properties.
>> > * the “resources” property of a datapackage seems to be functionally equivalent to our “tables” property for a TableGroup.
>> >
>> > There are more congruencies between the metadata formats, but they aren’t subsets of one or the other. It might be interesting if a future version of datapackages were more closely related to the CSVW metadata format.
>>
>> I actually wonder whether it is not possible to use the Metadata Format defined by this WG as the JSON Table Schema in the data package. Are there any fundamental reasons for having two different, though very similar, specifications out there? I think this is really a problem for the end
>> users… On the other hand, the data package work nicely complements the work that has been done in this Working Group.
>>
>> I hear you - I had hoped that we might keep a bit closer than we ultimately have there. There are some changes to the JTS that could be made e.g. swapping fields to columns. The one challenge is the growing set of tooling out there and not wanting breaking changes for people but ultimately it is possible on some things especially if one allowed aliases.
>>
>> If there is more that could be reverse merged that would be useful.
>
> Gregg listed some changes that sound harmless. But I did not have time to compare the two.
>
> As for implementations: CSVW has already one full implementation and others are in the making. So there we go…

Has anyone reviewing the CSVW specs to date raised this as a concern?
I see 4 specific points (either addressed or discussions amongst us)
listed in https://github.com/w3c/csvw/issues?utf8=%E2%9C%93&q=is%3Aissue+dataprotocols+
... but afaik no member of the wider public has flagged this
divergence as a concern. Not that consistency isn't good, just trying
to get a handle on the potential impact either way.

Dan

Received on Friday, 3 July 2015 12:56:18 UTC