Add severity levels that are not violations

[bergos]

sh:Info, sh:Warning, and sh:Violation are defined as violations. It would be good to have severity levels not defined as violations. They could show detailed information on which constraints have been processed.

shacl-engine already uses two new levels in its own namespace:

• Debug: Shows that a constraint has been processed.
• Trace: For property shapes without constraints showing the traversal path.

[HolgerKnublauch]

I have never quite understood why sh:Info counts as a violation.

[HolgerKnublauch]

See also https://datashapes.org/dash.html#results

[bergos]

We should have both; dash:*Result classes in the SHACL namespace and additional levels.

Info, Warning, and Violation (Error) match the typical levels of loggers with messages an end-user would see. Debug and Trace would be the levels for shape developers, like in the use cases I described previously.

The spec could explicitly mention that an implementation is allowed to have a parameter to change the severity level where the result becomes a failure/violation. With the default set to Info this would not be a breaking change. The new result classes should be used according to the setting given to the engine.

[robert-david]

What about "positive" matches of nodes which validate successfully?

[tpluscode]

What about "positive" matches of nodes which validate successfully?

As much as I support that because it would help finding cases where nothing was actually validated (no matching targets), we need to be careful around logical constraints.

Think sh:not. Positive matches from the negated constraints actually results in from sh:not. And as always, that becomes most interesting with sh:xone.

[ajnelson-nist]

[...] The spec could explicitly mention that an implementation is allowed to have a parameter to change the severity level where the result becomes a failure/violation. [...]

It may also be helpful to know what this tunable level was as part of the validation report. "sh:conforms false - because of the sh:Violations, or the sh:Warnings? How strict were they on this run?"

[robert-david]

[...] The spec could explicitly mention that an implementation is allowed to have a parameter to change the severity level where the result becomes a failure/violation. [...]

It may also be helpful to know what this tunable level was as part of the validation report. "sh:conforms false - because of the sh:Violations, or the sh:Warnings? How strict were they on this run?"

It might require a new 3rd value for sh:conforms.

[VladimirAlexiev]

What about "positive" matches of nodes which validate successfully?

@robert-david I support this need because it's useful to know. Especially for simple shapes like "node reference shape" that can be used to classify nodes (ONTO Semantic Objects calls this "business type discriminator").

@tpluscode can we at least provide a limited definition of "positive match" to cover common modeling subsets of shape features?