sh:pattern does not allow testing IRIs

[afs]

sh:pattern is defined by:

The values of sh:pattern in a shape are valid pattern arguments for the SPARQL REGEX function.

Right. And the first argument is a defined as literal.

# this is valid
BIND(regex(str(<>), 'foo') as ?foo)

# but this is not
BIND(regex(<>, 'foo') as ?foo)

Originally posted by @tpluscode in #228

Isn't this highlighted line a test of sh:pattern against an IRI ...

data-shapes/data-shapes-test-suite/tests/core/node/pattern-001.ttl

Line 15 in 380d4ee

sh:targetNode ex:Test ;

and this line the corresponding XFAIL result?

data-shapes/data-shapes-test-suite/tests/core/node/pattern-001.ttl

Line 41 in 380d4ee

sh:focusNode ex:Test ;

Originally posted by @ajnelson-nist in #228

[ajnelson-nist]

PR #231 opened for group review and discussion.

[VladimirAlexiev]

Like @tfrancart I was always certain that pattern can test any nodes.
No fix is needed to its definition since "valid pattern arguments" refers to the value of sh:pattern , I.e. to the regex (second argument of regex())

But a clarification is needed about the first argument

• it is converted to string
• (new) it is not recommended to use sh:pattern for numbers, dates or booleans since various different lexical representations can map to the same value. Eg all these pairs designate the same value:
  • 001 and 1 (xsd:integer)
  • 0.1 and 0.100 (xsd:decimal)
  • 0.1 and 0.100000009 (xsd:float)
  • 2025-01-31 and 002025-01-31 (xsd:date)
• (new) it is not recommended to use sh:pattern for blank nodes, unless you know they were generated using specified blank node names

[tpluscode]

• (new) it is not recommended to use sh:pattern for blank nodes, unless you know they were generated using specified blank node names

This is surely not a good idea. Blank node labels are almost certain to change any time a graph is parsed or transfered.

IMO, the only meaningful improvement appears to be the addition of explicit handling of IRIs. I would represent this in SPARQL as

BIN(REGEX(IF(ISIRI(?input), STR(?input), ?input), ?pattern) as ?five)

[ajnelson-nist]

• (new) it is not recommended to use sh:pattern for blank nodes, unless you know they were generated using specified blank node names

This is surely not a good idea. Blank node labels are almost certain to change any time a graph is parsed or transfered.

On the other hand, I could see some use cases involving documentation quality control where this would be desirable. I'm not sure if supporting that just makes a huge foot-cannon, though.

[afs]

If Core is being unlinked from SPARQL, it will be odd to continue to rely on STR(). I can't find any using of "lexical form" in SHACL-Core 1.0 - it does use the terminolgy "string representation", quite often with "(as defined by the SPARQL str function)" so make that a definition then clear-up.

(I hope there will continue to be a WG-approved (non-normative) list of constraint as SPARQL. An appendix?)

[HolgerKnublauch]

The intention was always to allow sh:pattern to be used on value nodes that are IRIs.

I see nothing wrong with the spec. It states that the values of sh:pattern must be strings (which they are) and that the value nodes need to be converted to their STR.

What specifically needs to be changed in the spec? (We can of course always add a non-normative clarification to explain that IRIs are fine).

I think it's fine to continue to reference definitions from SPARQL in Core, if that makes the contracts clear, easier to implement and avoids having to reinvent things.

[afs]

What specifically needs to be changed in the spec? (We can of course always add a non-normative clarification to explain that IRIs are fine).

I think it's fine to continue to reference definitions from SPARQL in Core, if that makes the contracts clear, easier to implement and avoids having to reinvent things.

Its the "1.1" effect! What was fine in a 1.0 needs refining as it becomes successful.

Imagine implementing the core profile on its own.

string representation should be <dfn> defined once and then used (all places). ¹²
For definitions of a constraint, the doc should be using <a>string representation</a> and referring to what it cares about.
All the "(as defined by the SPARQL str function)" can then be replaced.

https://www.w3.org/TR/xpath-functions/#func-matches
https://www.w3.org/TR/xpath-functions/#regex-syntax

Clarity and implementation help are non-normative (as are tests as far as definitions are concerned).

Footnotes

1. Details matter! What about surrogates? lone or in pairs? ↩

2. https://www.w3.org/TR/rdf12-concepts/#dfn-rdf-string ↩

[VladimirAlexiev]

@tpluscode

Blank node labels are almost certain to change any time a graph is parsed or transfered.

Yes. But you can fix the name in CONSTRUCT or UPDATE.
Anyway, I also agree that checking for specific bnode names is a bad practice.

the only meaningful improvement appears to be the addition of explicit handling of IRIs.

So do you want to FORBID it for numbers and dates?