"Concepts" enhancements for Fiscal Data Package

[pwalsh]

Description

The following issues should be addressed:

• Support for measure normalization openspending/fiscal-data-package#141
• On Location openspending/fiscal-data-package#140
• Add Latitude and Longitude to Location Dimension openspending/fiscal-data-package#79
• Remove suggested location attributes from "entity" dimension openspending/fiscal-data-package#139
• Display name for dimensions openspending/fiscal-data-package#137
• Change suggested "id" attributes to "code" attributes throughout spec openspending/fiscal-data-package#126
• Names should be unique across measures and dimensions openspending/fiscal-data-package#113
• Links to ID schemas openspending/fiscal-data-package#15 (maybe a bit out of date as actually refers to Budget Data Package, the predecessor to Fiscal Data Package)

Note that this is also a testing ground for introducing "Concepts" more generally to the Frictionless Data spec family.

Tasks

• @pwalsh to review OBEU Data Model and US DATA Act in detail
• @pwalsh to review schema.org and other vocabularies for concepts
• @akariv to present first take that extract his work on OS Types, already used in OpenSpending and on Fiscal Data Package
• @akariv to review the above linked issues and confirm they are addressed by the enhanced implementation

[pwalsh]

Dropping this here so I can review later https://gist.github.com/pwalsh/a9f7f0796229d0566191

[pwalsh]

Requires frictionlessdata/datapackage#529

[pwalsh]

@akariv

Can you:

1. Add here a brief description, and a collection of sample snippets, of the new syntax/handling being proposed for v1.
2. Review the linked issues above to ensure they are all handled.
3. Additionally, link to the current text of the v1 spec in whole.

[akariv]

This is the current working draft of the spec https://hackmd.io/BwNgpgrCDGDsBMBaAhtALARkWsPEE5posR8RxgAzffWfDIA=?view

I believe most of the linked issues (if not all) were addressed by the conceptual change that we're introducing and the move to the more flexible ColumnTypes.
While I recommend reading the spec draft for a more in-depth explanation, the basic idea is that semantic mapping of the file into fiscal concepts is done via an easily extensible taxonomy of fiscal concepts. While this spec provides an extensive list of base types, it also provides the means to extend that taxonomy by creating sort-of-speak 'extension packs' (for various needs) or even ad-hock definition of types within the package descriptor itself.