Support the correct nodeKind determination for a limited sh:or scenario #13

Merged
jsheunis merged 3 commits from shor into main 2025-07-24 20:18:45 +00:00
jsheunis commented 2025-07-24 20:13:59 +00:00 (Migrated from github.com)

This change is a temporary feature in response to the ShaclORClassEditor
that was introduced to shacl-vue in d1b8a8c445a394119cc4a520fccc7b8c560fdb51.
The ShaclORClassEditor specifically matches propertyShapes that have sh:or and
where all elements in the sh:or array have an sh:class key. This makes it simple
to assume that the corresponding value would be a namedNode, which is also what
getPropertyNodeKind has been updated to return.

This feature is not intended to fully support any sh:or scenario, only to have
parity with shacl-vue to the level that the latter supports sh:or.

Future changes should consider moving the determination of a property's nodekind
to shacl-vue itself, at the point where data is entered into the UI. This would
prevent the necessity of having to determine the nodeKind for what could be very
complicated recursive sh:or arrays with a variety of nodekinds.

Tests are also updated.

This closes #12. A new issue should be opened for supporting the full range of sh:or

This change is a temporary feature in response to the ShaclORClassEditor that was introduced to shacl-vue in d1b8a8c445a394119cc4a520fccc7b8c560fdb51. The ShaclORClassEditor specifically matches propertyShapes that have sh:or and where all elements in the sh:or array have an sh:class key. This makes it simple to assume that the corresponding value would be a namedNode, which is also what getPropertyNodeKind has been updated to return. This feature is not intended to fully support any sh:or scenario, only to have parity with shacl-vue to the level that the latter supports sh:or. Future changes should consider moving the determination of a property's nodekind to shacl-vue itself, at the point where data is entered into the UI. This would prevent the necessity of having to determine the nodeKind for what could be very complicated recursive sh:or arrays with a variety of nodekinds. Tests are also updated. This closes #12. A new issue should be opened for supporting the full range of `sh:or`
Sign in to join this conversation.
No description provided.