Extending SHACL - non standard features discussion #3186
Replies: 3 comments
-
I'm fine with that in principle, though I'd like to make it explict/configurable if those extensions are active - and if at all possible, I'd like to see if we can physically separate standard and non-standard features in the code base as well (subclassing, separate modules, using injection, whatever's appropriate). Priority-wise though, I would prefer if we focused on getting full standards compliance first. Not only because I think having full standards compliance "looks good" in the wider community, but also because I could easily imagine us falling into the trap of doing non-standard things as feature requests which could have been solved a different way using spec-compliant features (not suggesting any on the current list are in that category btw).
I would definitely try and get their input for any particular use case, to introduce the solution we are thinking of, and see what their thoughts are. Send an e-mail to the SHACL list with a short explanation of the use case and an invitation to provide feedback? I don't think we can advocate making a particular feature part of the standard (or advanced notes spec) until we've actually implemented it. But early feedback might help us steer the design in a direction that has a high chance of wider adoption.
I'd say it's important to make it a configurable option and not default behavior. Model-wise I also think it's important that non-standard features have their own namespace, so it's clear what is standard SHACL and what isn't.
Certainly if a feature request comes in that is (in part or fully) covered by that document, I would attempt to solve it following that spec, not come up with our own alternative.
I would suggest we certainly mark everything we do in this space as experimental and subject to change. Dropping support for our own feature if something similar becomes standard is something we'd have to look at on a case-by-case basis, but generally I'd say we'd mark our feature deprecated, and/or look at possible support to make automated migration possible. |
Beta Was this translation helpful? Give feedback.
-
I also think this is the best approach. Users would need to explicitly enable these features, and thus becoming aware that they are enabling features that are more likely to change or be removed. |
Beta Was this translation helpful? Give feedback.
-
Agree with everything above. I'd also add "try to get the feature in the datashapes.org spec". Holger has been very helpful and forthcoming, so once a feature has been discussed on the mailing list and justified with cases, that should be possible. |
Beta Was this translation helpful? Give feedback.
-
The ShaclSail is around 50% compliant with the SHACL standard and we are already discussing adding features that are outside of the standard.
Examples of such features:
actual
andexpected
I would like to discuss the following:
Beta Was this translation helpful? Give feedback.
All reactions