Difference between revisions of "Data Dictionaries"

Jump to navigation Jump to search
27 bytes added ,  20:44, 9 March 2022
Move table out of list to improve parsing of Markdown
(Add table of CKAN types)
(Move table out of list to improve parsing of Markdown)
 
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]).
* "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.
 
{| class="wikitable"
{| class="wikitable"
|+  
|+ Table 1
|-
|-
! CKAN type !! description
! CKAN type !! description
Line 39: Line 42:
| json || a JSON representation of some data (superuseful but by far the most obscure type on this list)
| json || a JSON representation of some data (superuseful but by far the most obscure type on this list)
|}
|}
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".
* "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.


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.

Navigation menu