{"action":"created","issue":{"url":"https://api.github.com/repos/openspending/fiscal-data-package/issues/93","labels_url":"https://api.github.com/repos/openspending/fiscal-data-package/issues/93/labels{/name}","comments_url":"https://api.github.com/repos/openspending/fiscal-data-package/issues/93/comments","events_url":"https://api.github.com/repos/openspending/fiscal-data-package/issues/93/events","html_url":"https://github.com/openspending/fiscal-data-package/issues/93","id":120033382,"number":93,"title":"Various notes from trying to implement","user":{"login":"pudo","id":41628,"avatar_url":"https://avatars.githubusercontent.com/u/41628?v=3","gravatar_id":"","url":"https://api.github.com/users/pudo","html_url":"https://github.com/pudo","followers_url":"https://api.github.com/users/pudo/followers","following_url":"https://api.github.com/users/pudo/following{/other_user}","gists_url":"https://api.github.com/users/pudo/gists{/gist_id}","starred_url":"https://api.github.com/users/pudo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pudo/subscriptions","organizations_url":"https://api.github.com/users/pudo/orgs","repos_url":"https://api.github.com/users/pudo/repos","events_url":"https://api.github.com/users/pudo/events{/privacy}","received_events_url":"https://api.github.com/users/pudo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-12-02T20:51:50Z","updated_at":"2015-12-03T07:51:59Z","closed_at":null,"body":"Just for fun, I'm trying to hack up a FDP->babbage->FDP translator based on [Dan's code](https://github.com/openspending/cubepress/blob/load-from-datapackage/cubepress/model/util.py). As some feedback, here's a sort of stream of consciousness of the issues that come up during this implementation effort:\r\n\r\n### Problems\r\n\r\n* ``source`` is a weird name for the column thing. It's a really, really overloaded term. Why not ``field``? \r\n* The term ``field`` is overloaded between resources and dimensions (both are often used in the same code, I'd guess). Proposing ``attribute`` (ref #40). \r\n* Why is the model called ``mapping``, when mapping columns is only a small part of what it does? This is a mistake we already made in OpenSpending, now is the time to correct it. \r\n* Allowing the ``primaryKey`` on a dimension to be a list seems a bit too flexible to me, what's the use case? How would I stuff that into an aggregation call, or generate a URL?\r\n* When describing dimensions, the spec mentions both ``id`` and ``code`` fields. Which of these is better? How do they relate to ``primaryKey``?\r\n* At the same time, I still can't tell how to determine label fields for a dimension.\r\n* Is there no difference between the user-facing name and the column name of a dimension, measure or dimension field?\r\n* What is supposed to happen if the model includes columns from multiple resources? I can't find instructions on how to join them in the TDP spec (maybe too stupid?).\r\n\r\n### Opinions\r\n\r\n* How did ``phase`` and ``direction`` end up as attributes on the measure? While I agree that source budget data with multiple measures is quite common, I cannot see a clear difference between these two attributes and other dimensions. I want to break them down the same way I would break down a sector or a supplier, rather than by fiddling with multiple measures. (ref #91 - the discussion there confuses the living daylight out of me)\r\n* There are also more types of phases and directions (the last dataset I added to OHa has directions \"revenue\", \"expenditure\", \"internal paid\", \"internal received\", \"balance\").\r\n* Making everything a list makes sense in JTS (to preserve order), but just makes life a little harder for everything in the model (ref #90, #54).\r\n* Proposing that code sheets separate keys with a dot is very cofog-specific, many taxonomies just use string-numbers (i.e. 0, 01, 011 for three levels).\r\n"},"comment":{"url":"https://api.github.com/repos/openspending/fiscal-data-package/issues/comments/161543712","html_url":"https://github.com/openspending/fiscal-data-package/issues/93#issuecomment-161543712","issue_url":"https://api.github.com/repos/openspending/fiscal-data-package/issues/93","id":161543712,"user":{"login":"danfowler","id":772616,"avatar_url":"https://avatars.githubusercontent.com/u/772616?v=3","gravatar_id":"","url":"https://api.github.com/users/danfowler","html_url":"https://github.com/danfowler","followers_url":"https://api.github.com/users/danfowler/followers","following_url":"https://api.github.com/users/danfowler/following{/other_user}","gists_url":"https://api.github.com/users/danfowler/gists{/gist_id}","starred_url":"https://api.github.com/users/danfowler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danfowler/subscriptions","organizations_url":"https://api.github.com/users/danfowler/orgs","repos_url":"https://api.github.com/users/danfowler/repos","events_url":"https://api.github.com/users/danfowler/events{/privacy}","received_events_url":"https://api.github.com/users/danfowler/received_events","type":"User","site_admin":false},"created_at":"2015-12-03T07:51:59Z","updated_at":"2015-12-03T07:51:59Z","body":"> The term field is overloaded between resources and dimensions (both are often used in the same code, I'd guess). Proposing attribute (ref #40). \r\n\r\nThanks @pudo.  I made a similar point [here](https://github.com/openspending/fiscal-data-package/issues/48#issuecomment-160751866) in a long discussion about restructuring the dimension object to support hierarchies.  A given dimension `field` potentially, though not always, maps to multiple source `fields`."}}