-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
URI vs Slug vs String #18
Comments
One possible problem with (blindly) passing values into templates is that we don't have context-sensitive validation of the inputs - i.e. it would be possible to provide invalid values like We may be able to solve this using datatypes. Although, if we need to coin our own ( Alternatively we could ignore the problem at this level and instead pick it up with a later validation. We will in any case validate that dimension-values are recognised (i.e. ASK that Note that cases with |
Adds HMRC Overseas Trade example and starts removing hard-coded config specific to the regional-trade example as per #22. The `is-dimension?` and `is-attribute?` sets are now drawn from the conventions - i.e. those columns with the respective component attachment property. The `values` seq now uses an equivalent `is-value?` set which includes those columns for which the conventions don't specify a component attachment (i.e. if the column is not a dimension, measure, or attribute then it must be a value). `standardise-measure` is now just `title->name` `slugize-columns` is replaced by `transform-columns` which is configured by a new convention: `value_transformation` which also allows us to specify e.g. a `replace-symbols` transform (#18 may later allow us to derive these instead of setting them explicitly).
The new loading architecture suggests to me a possible solution to the stringy-identifiers problem:
datatype
asstring
:value-template
, then cell value should be treated as ready for that template (i.e. already slugged or a code without spaces)qb:codeList
then use the value in that cell to lookup a code by it's labeldatatype
isnumber
:datatype
isxsd:anyURI
Given that multiple column names could theoretically be used to populate the same component, this gives us quite a bit of flexibility. For example, for specifying a reference period you might provide three columns all having
sdmx-dim:refPeriod
in theirproperty_template
configuration, but each with a differentvalue_template
:"http://reference.data.gov.uk/id/year/{year}"
accepting values like"2018"
"http://reference.data.gov.uk/id/government-year/{government-year}"
accepting values like"2017-2018"
"http://reference.data.gov.uk/id/{reference_period}"
(a generic fallback) accepting values like"government-quarter/2009-2010/Q1"
Thus the uploader would indicate which kind of date they'd provided by using the appropriate column heading. They could then provide more than one kind of interval by either splitting the upload or by providing multiple (non-overlapping) columns in the table (i.e. some rows having Years, others Government Years but none both).
One implication of this is that we wouldn't be slugging anything in the observations input csv! We could still need to do so as part of the code-list pipeline (i.e. to create an
skos:notation
where none was provided).The text was updated successfully, but these errors were encountered: