Re: Data Package RFCs coming up ...

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.

Rufus


>
> Just my 2 cents…
>
> Ivan
>
>
> >
> >> Regards,
> >>
> >> Rufus
> >> --
> >> Rufus Pollock
> >> Founder and President  |  skype: rufuspollock  |  @rufuspollock
> >> Open Knowledge - see how data can change the world
> >> http://okfn.org/  |  @okfn  |  Open Knowledge on Facebook  |  Blog
> >
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>


-- 

*Rufus PollockFounder and President | skype: rufuspollock | @rufuspollock
<https://twitter.com/rufuspollock>Open Knowledge <http://okfn.org/> - see
how data can change the world**http://okfn.org/ <http://okfn.org/> | @okfn
<http://twitter.com/OKFN> | Open Knowledge on Facebook
<https://www.facebook.com/OKFNetwork> |  Blog <http://blog.okfn.org/>*