73
edits
Difference between revisions of "Data Dictionaries"
Jump to navigation
Jump to search
Move table out of list to improve parsing of Markdown
(Add Data Dictionaries page) |
(Move table out of list to improve parsing of Markdown) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 17: | Line 17: | ||
The fields we recommend are: | The fields we recommend are: | ||
* "column": The name of the field. (Preferably formatted in all lowercase letters and with underscores instead of spaces or other punctuation.) | * "column": The name of the field. (Preferably formatted in all lowercase letters and with underscores instead of spaces or other punctuation.) | ||
* "type": The type of the field, coded as something like "text" or "float" or "int". The [http://docs.ckan.org/en/latest/maintaining/datastore.html#field-types full list of types for values that go into the CKAN datastore] (which the WPRDC data portal runs on) is | * "type": The type of the field, coded as something like "text" or "float" or "int". The [http://docs.ckan.org/en/latest/maintaining/datastore.html#field-types full list of types for values that go into the CKAN datastore] (which the WPRDC data portal runs on) is shown in Table 1 below. Note that when using CKAN's integrated data dictionaries, the type of a data dictionary entry is set by the type of the field in the CKAN datastore, so you shouldn't have to set this yourself (unless you need to override the type that CKAN thinks that field is [this is only for a non-ETL upload]). | ||
Note that when using CKAN's integrated data dictionaries, the type of a data dictionary entry is set by the type of the field in the CKAN datastore, so you shouldn't have to set this yourself (unless you need to override the type that CKAN thinks that field is [this is only for a non-ETL upload]). | |||
* "label": A short human-readable label for this field. If the field name is <code>zip</code>, an appropriate label might be "ZIP Code" or "Postal Code". | * "label": A short human-readable label for this field. If the field name is <code>zip</code>, an appropriate label might be "ZIP Code" or "Postal Code". | ||
* "description": A definition of the field (you could, for instance, include in here that the units of the field value are furlongs). This is also the place to put any other information relevant to the field, including information about how the field was calculated from another field or how the field was transformed for publication. | * "description": A definition of the field (you could, for instance, include in here that the units of the field value are furlongs). This is also the place to put any other information relevant to the field, including information about how the field was calculated from another field or how the field was transformed for publication. | ||
{| class="wikitable" | |||
|+ Table 1 | |||
|- | |||
! CKAN type !! description | |||
|- | |||
| text || text string | |||
|- | |||
| int || integer | |||
|- | |||
| float || real number | |||
|- | |||
| boolean || a Boolean value (True or False) | |||
|- | |||
| date || a date without a time | |||
|- | |||
| time || a time without a date | |||
|- | |||
| timestamp || a date and a time together (a.k.a., a "datetime") | |||
|- | |||
| json || a JSON representation of some data (superuseful but by far the most obscure type on this list) | |||
|} | |||
We also like [https://opendata.stackexchange.com/a/319 the Frictionless Data JSON Table Schema example] approach to data dictionaries, but we're not quite ready for that yet. | We also like [https://opendata.stackexchange.com/a/319 the Frictionless Data JSON Table Schema example] approach to data dictionaries, but we're not quite ready for that yet. | ||