-
Notifications
You must be signed in to change notification settings - Fork 2
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
mixed node kind in cube data #1469
Comments
I the correct node kind set when you transform again after editing the metadata? |
by "editing the metadata" you mean for example linking every value to some shared dimension term? Because the node kind is set by the pipeline (<#toCubeShape>) based on the actual observations (and does not cover |
@giacomociti WRT the spec at https://cube.link/#null-empty-values ... so nodeKind would be consistently IRI 👍 |
agreed, we should be using There is an external application which may be affected by the change, so we'll probably evolve both the cube and the app in the future. |
@giacomociti to increase the reusability of first brainstorming: cube:Undefined schema:name "Undefined" , "Undefined"@en , "Unbestimmt"@de , "Indéfini"@fr , "Indefinito"@it , "Indefini"@rm . possibly other attributes i.e. WDYT? cube:Undefined schema:identifier ""^^cube:Undefined ;
schema:position ""^^cube:Undefined . |
Describe the bug
Affected functionalities (all that apply)
Relevant links
query returning an example of inconsistent data (a dimension with
constraint
sh:nodeKind sh:IRI
but having both IRI and literal values).To Reproduce
Steps to reproduce the behavior:
Expected behavior
The constraint for the dimension should have
sh:nodeKind sh:IRIOrLiteral
instead ofsh:IRI
.Screenshots
Desktop (please complete the following information):
Additional context
There is a proposal of disallowing mixed node kinds. If applied, cube creator should prevent publishing invalid data.
The text was updated successfully, but these errors were encountered: