Following from the discussion in #69, we might look to make the observation-uri template configurable.
This would allow us to coin observation URIs with hashes (instead of a long collation of dimension & value slugs).
We could do this within table2qb (e.g. deriving a observation-guid field from the dimension-properties and dimension-values). If the hashing operation is expensive, we might only want to do that lazily. Alternatively we could allow users to provide this in a non-component/ non-value column (with #124).
Customisable observation-uris would also allow us to recreate linked-data following other conventions (e.g. extending the kubus luchtemisses example to cover observation-uris). Writing templates by hand will be tricky (you'd need to guarantee uniqueness) so might want to support users with some means of validating uniqueness.
Following from the discussion in #69, we might look to make the observation-uri template configurable.
This would allow us to coin observation URIs with hashes (instead of a long collation of dimension & value slugs).
We could do this within table2qb (e.g. deriving a
observation-guid
field from the dimension-properties and dimension-values). If the hashing operation is expensive, we might only want to do that lazily. Alternatively we could allow users to provide this in a non-component/ non-value column (with #124).Customisable observation-uris would also allow us to recreate linked-data following other conventions (e.g. extending the kubus luchtemisses example to cover observation-uris). Writing templates by hand will be tricky (you'd need to guarantee uniqueness) so might want to support users with some means of validating uniqueness.