Put variables in virtual columns so we don't need a meta-templating language

[Robsteranium]

We currently have a meta-templating language for defining URI templates. This allows you to include variables that aren't available within the csv table - like $(base-uri).

@RickMoynihan has suggested that we could instead provide variables as virtual columns:

{
  "name": "base_uri",
  "virtual": true,
  "default": "http://gss-data.org.uk/",
  "suppressOutput": true
}

These could then be used in templates like normal variables:

"aboutUrl": "{+base_uri}/def/{component_type_slug}/{notation}"

This would obviate the need for a meta-templating language.

This would involve a range of changes including:

• The CLI tool and it's help docs would need updating
• In resources/table2qb-config.edn template-vars would become csvw-vars
• We would need to re-write many (probably all) of the schemas and default templates
• Users would need to re-write any custom uri templates

[danbri]

I was myself just wondering how close your mapping was to the csvw table to rdf mechanism, although you’re using multiple tables…

[danbri]

Related example from Jeremy Tandy:

https://github.com/w3c/csvw/blob/gh-pages/examples/rdf-data-cube-example.md

[Robsteranium]

You can see the journey from csv => csvw in the regional-trade example.

The key part is the value_transformations (like sluggising) but we're also outputting structure - as in the component-specification.csv. We have considered using the JSON-LD metadata for the Cube it's DSD instead of CSV as per the Cambourne weather example. Indeed this is what colleagues at ONS have since chosen to do.