Constraints for simple tasks

[afs]

Having specific forms for simple cases:

• (users) it makes it clearer to see what a constraint does; less error-prone.
• (implementers) helps implementation/optimization, avoiding analysis regexes; for light-weight implementations.

e.g. for strings:

• sh:strContains
• sh:strStarts, sh:strEnds

This can already be performed by sh:pattern but being able to say them without regexs is easier.

eg. for URIs:

• some way to say "in namespace" (effectively, URI prefix)

[HolgerKnublauch]

Thinking out loud, theoretically, one way of addressing this and similar use cases would be to adopt Expression Constraints (https://w3c.github.io/shacl/shacl-af/#ExpressionConstraintComponent) - Node Expressions that must return true or otherwise flag a violation. Assuming we want to have these SPARQL functions in node expressions anyway, it could then be written as

ex:SomeShape-someProperty
    a sh:PropertyShape ;
    sh:path ex:someProperty ;
    sh:expression [
        sparql:STRSTARTS ( sh:this "SomeString" ) ;
    ] .

This is, of course, more verbose than

ex:SomeShape-someProperty
    a sh:PropertyShape ;
    sh:path ex:someProperty ;
    sh:strStarts "SomeString" .

but then it doesn't need to reinvent the wheel and introduce a constraint component for every conceivable scenario.

... Or maybe there is a pattern here and we can make various node expressions/functions also be useable as constraints by default?

[tpluscode]

... Or maybe there is a pattern here and we can make various node expressions/functions also be useable as constraints by default?

Maybe this could be possible as some kind of alias. In the example above, one could defined sh:strStarts as a shorthand. Here's an illustration of such a alias using N3 rule, which should make the idea clear.

{
  ?shape 
    a sh:NodeShape ;
    sh:strStarts ?value ;
  .
} => {
  ?shape 
    sh:expression [
      sparql:STRSTARTS ( sh:this ?value ) ;
    ] .
} .

Without using Node Expressions, one could also use sh:pattern

{
  ?shape 
    a sh:NodeShape ;
    sh:strStarts ?value ;
  .

  ( "^" ?value ) string:concatenation ?pattern .
} => {
  ?shape sh:pattern ?pattern 
} .

[afs]

( "^" ?value ) string:concatenation ?pattern .

Beware metacharacters in the regex.

The motivation is

1. For implementers - the operation is done directly which significantly faster
2. For users, it is clearer what they are writing.

to reinvent the wheel and introduce a constraint component for every conceivable scenario.

Yes, there needs to be a balance.

[HolgerKnublauch]

I think there is little appetite to add these as core constraint components. Functions like strStarts are in SPARQL so it is fair to assume they may rather become node expressions. So I am tempted to remove the Core label - please undo if you disagree.

[afs]

Providing this via node expressions is fine.

There should be a way to have a node expression constraint. Would that go in core doc or the node expressions doc?

If we agree on that , I'll raise an issue for it.

   [
      sh:path ex:property ;
      sh:condition [ node_expression ]
   ]

sh:condition being sh:expression above with a name about being a boolean for a possible violation.

Other possibilities sh:constraint, sh:where, sh:requiring

[HolgerKnublauch]

Yes I think this should become a new ticket and I'd be happy to see that in Core.

In SHACL-AF this was called sh:expression https://w3c.github.io/shacl/shacl-af/#ExpressionConstraintComponent
In SHACL-AF, sh:condition is used for shapes, not node expressions, so I don't think we can reuse that here easily.

I would also be OK with sh:where or what about sh:isTrue and sh:isFalse?

[afs]

Issue #357

The use of sh:condition as part of a property shape looks compatible with the SHACL-AF use to me.

We have many new features and vocabulary is at a premium. We should automatically take SHALCL-AF is vocabulary owner.

Naming discussion on #357.