Need to think further about this. Removed the material below from the current spec since this is not finalized.
Current Primary Proposal
Making your registry into a (tabular) Data Package. A real-life example here:
https://github.com/datasets/registry
Here's the rough structure:
datapackage.json
catalog.csv
catalog.csv is a CSV file with the following structure:
url
: url to the dataset, usually the URL to the github repository
name
: the name of the dataset as set in its datapackage.json
(will
usually be the same as the name of the repository)
owner
: the username of the owner of the package. For datasets in github
this will be the github username
name
and owner
are both optional.
# OLD
Options
Option 1
[
{ data-package },
{ data-package }
]
Option 2
{
dp-id: { data-package },
dp-id: { data-package }
}
Option 3
{
dataPackageCatalogVersion: [an integer indicating version of the spec this corresponds to]
dataPackages:
like option 1 or 2 ...
...
}
Existing material
Catalogs and Discovery
In order to find Data Packages tools may make use of a "consolidated" catalog
either online or locally.
A general specification for (online) Data Catalogs can be found at
http://spec.datacatalogs.org/.
For local catalogs on disk we suggest locating at "HOME/.dpm/catalog.json" and
having the following structure::
{
version: ...
datasets:
{name}: {
{version}:
metadata: {metadata},
bundles: [
url: ...
type: file, url, ckan, zip, tgz
]
}
When Package metadata is added to the catalog a field called bundle is added
pointing to a bundle for this item (see below for more on bundles).