Source vs Compiled for data (packages) [Musings]


#1

Moved here from https://github.com/frictionlessdata/specs/issues/120 (May 17 2014)

Source / complied distinction is common in code. I think there is a good and relevant analogy with data. Best explained by some concrete examples:

  • Normalized to de-normalized. Source data is normalized (for efficiency and structure) but compiled might be one denormalized file. Good example here the CRA (~UK budget) dataset in OpenSpending - https://github.com/openspending/dpkg-cra. This is pretty simple tabular dataset. Normalizing leads to a 4-5x reduction in file size but when loading into OpenSpending you need to denormalize to a single file.

One can also think of things like:

  • Spreadsheet => PDF
  • geodata => tiles

I think for our purposes these are less relevant examples.

This is relevant because I think data package creators and managers (curators) want to work with source but consumers will often want compiled. Good analogy here with code and specifically Debian: in Debian the packager will often create pre-compiled versions of the software which debian users then install via apt-get with these pre-compiled versions stored in the primary ftp storage area.

So overall I can imagine an architecture like this:

  • Source data packages stored in git or ckan or …
  • Defined compilation pattern / step (e.g. a datapackage has a scripts/make or scripts/compile)
  • Pre-Compiled versions cached into file storage (s3 etc)