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

mixed node kind in cube data #1469

Open
1 of 4 tasks
giacomociti opened this issue Oct 24, 2023 · 5 comments · May be fixed by #1517
Open
1 of 4 tasks

mixed node kind in cube data #1469

giacomociti opened this issue Oct 24, 2023 · 5 comments · May be fixed by #1517
Assignees
Labels
🐛 bug Something isn't working
Milestone

Comments

@giacomociti
Copy link
Contributor

Describe the bug

Affected functionalities (all that apply)

  • CSV Mapping
  • Transformation
  • Publishing
  • Other

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:

  1. Create a new cube from CSV
  2. Apply transformation
  3. Edit metadata linking to a shared dimension some values of a dimension (but not all of them)
  4. Publish

Expected behavior

The constraint for the dimension should have sh:nodeKind sh:IRIOrLiteral instead of sh:IRI.

Screenshots

Desktop (please complete the following information):

  • OS: Windows 11
  • Browser: chrome

Additional context

There is a proposal of disallowing mixed node kinds. If applied, cube creator should prevent publishing invalid data.

@tpluscode
Copy link
Collaborator

I the correct node kind set when you transform again after editing the metadata?

@giacomociti
Copy link
Contributor Author

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 sh:IRIOrLiteral unlike the new implementation in barnard59). So the only chance to avoid the issue is to ensure all the values for a dimension have the same node kind (either IRI or Literal)

@Rdataflow
Copy link

Rdataflow commented Apr 26, 2024

@giacomociti WRT the spec at https://cube.link/#null-empty-values
it would be the most obvious to reuse cube:Undefined in this case.

... so nodeKind would be consistently IRI 👍

@giacomociti
Copy link
Contributor Author

agreed, we should be using cube:Undefined.

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.

@Rdataflow
Copy link

@giacomociti to increase the reusability of cube:Undefined it might be good to establish labels using schema:name and maybe some other useful properties.

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 .

@tpluscode tpluscode added this to the s5.9 milestone May 14, 2024
@the-zazukoian the-zazukoian bot linked a pull request May 23, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working
Projects
Status: Deployed on TEST
Development

Successfully merging a pull request may close this issue.

3 participants