Require hierarchy name

[tpluscode]

    Found an interesting edge-case: [https://s.zazuko.com/xmbYnD]()

    We have here a cube, with a dimension with 13 distinct hierarchies parallel to each other. Using `cat cube-constraint.ttl | npx barnard59 cube check-metadata --profile https://cube.link/latest/shape/standalone-constraint-constraint` returns no errors.

    Nevertheless, Visualize can't handle this case:
    ![image](https://github.com/zazuko/cube-link/assets/95312586/5c5905a3-6f13-4cae-b6ca-3ced6fe89832)

    The visualization issue can be fixed rather easily by giving each hierarchy a distinct name. Would it be possible to catch this issue in the `standalone-constraint-constraint.ttl`?

    cc @Rdataflow @tpluscode

Originally posted by @kronmar in https://github.com/zazuko/cube-link/issues/114#issuecomment-1927194177

[tpluscode]

I created this issue referencing your comment @kronmar, but I find that schema:name is already required by the shape. Cube Creator also enforces it. Where are these offending cubes coming from?

https://github.com/zazuko/cube-link/blob/23357ab0c30285683172aa3b3bc34a18c4c106ff/validation/standalone-constraint-constraint.ttl#L207-L211

[kronmar]

The offending cubes come from our own pipeline.

The issue is, that standalone-constraint-constraint checks that all hierarchies (that is in this specific cubes all parallel hierarchies) have a name. But they can have all the same name. Which breaks visualize and begs the question whether it would actually make sense for parallel hierarchies to have the same name?

cc @Rdataflow

[tpluscode]

I don't understand. Would you share a query showing such a cube?

[kronmar]

Just realised, the link in the initial comment wasn't working. Fixed it, but here as well https://s.zazuko.com/3C25xc2

[tpluscode]

Yes, it's weird that all these hierarchies are called Classification. Unfortunately, I think it may be difficult to handle enforce such uniqueness with plain SHACL.

I don't think it's really harmful "enough" to enforce with standard profiles.

[kronmar]

Does the validator support SPARQL-based constraints?

[tpluscode]

Not the current implementation. It's certainly on our radar. Either by switching to a different tool or implementing ourselves: https://github.com/zazuko/rdf-validate-shacl/issues/104

[kronmar]

Found a possible solution without using SPARQL-based constraints:

https://s.zazuko.com/ERuwjt It's not an ideal solution, as it targets all hierarchies, maybe that could be solved tho.

[tpluscode]

That does not work, because targets are not combined. That shape will actually target everything that has schema:name. Not only hierarchies