Skip to content
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

dimensions of scaleType nominal and ordinal shall have a sh:in list of their elements regardless the datatype #328

Open
Rdataflow opened this issue Sep 13, 2024 · 1 comment
Assignees

Comments

@Rdataflow
Copy link
Contributor

cubes can have nominal or ordinal dimensions of Literals i.e. Integer

also in those cases we expect those dimensions to have a list of their elements attached at sh:in

i.e. a cube like https://s.zazuko.com/2k9QjTi having a nominal dimension containing a single value of "50"^^xsd:integer shall have a shape containing

<dim> sh:in ( 50 ) .

use case - see Info for https://energy.ld.admin.ch/sfoe/bfe_ogd56_energieperspektiven2050/KKWLaufzeit on
https://cube-validator.lindas.admin.ch/validate/https:%2F%2Ftest.lindas.admin.ch%2Fquery/https:%2F%2Fenergy.ld.admin.ch%2Fsfoe%2Fbfe_ogd56_energieperspektiven2050%2F3?tab=cube

@tpluscode
Copy link
Contributor

ping @l00mi

From what I understand, it has been by-design that numeric dimensions always generate sh:minValue/sh:maxValue constraints and not sh:in. Or is it ok to force sh:in for all nominal and ordinal dimensions regardless of their values.

I think the problem might be that calculating the constraints is not in any way connected to the metadata. In other words, we don't know the dimension's data kind when building a sh:in list (or not)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants