SHACL vocabulary is inconsistent

[wouterbeek]

The SHACL vocabulary may be inconsistent, since it states that namespaces must be URIs:

sh:namespace rdfs:range xsd:anyURI.

but at the same times defines its own namespace with a string:

sh:
  sh:declare
    [ sh:namespace "http://www.w3.org/ns/shacl#" ].

The easiest fix here is probably to change the above literal to:

"http://www.w3.org/ns/shacl#"^^xsd:anyURI

[HolgerKnublauch]

Yes I agree this is a glitch. You have already outlined the fix. I don't think I am permitted to simply change that file because we are outside of a W3C Working Group. I guess once a SHACL 1.1 WG is created this would be an item to fix. The current Errata already links to this GitHub issues list, so it will be remembered until then.

https://www.w3.org/2017/shacl/errata

Meanwhile the issue would only be reported as an inconsistency if someone would define a SHACL constraint on sh:namespace. rdfs:range by itself doesn't do any "harm".

This ticket will remain open.

[ashleysommer]

@HolgerKnublauch
This issue just appeared to me in the form of a bug reported on PySHACL: RDFLib/pySHACL#61

PySHACL implements the sh:declare feature with the rules defined in https://www.w3.org/TR/shacl/#sparql-prefixes

It states:

The values of sh:namespace are literals of datatype xsd:anyURI.

PySHACL has logic to throw an error when loading a SHACL Constraint, if that constraint has sh:prefixes that are invalid. And perhaps heavy-handedly pySHACL considers a sh:namespace without type xsd:anyURI to be invalid.

This bug has been around since 2017, but it hasn't been a problem because normally shacl.ttl isn't imported into the SHACL shapes graph.

It has come up in this case because:

1. Schema.org Shapes file owl:imports DASH shapes file
2. DASH Shapes file owl:imports shacl.ttl
3. shacl.ttl creates a sh:declare node, with sh:namespace being a string literal, not an xsd:anyURI
4. DASH Shapes file owl:imports TOSH Shapes file
5. TOSH Shapes file declares a SHACLFunction that references prefixes, including the broken sh prefix declaration from shacl.ttl

• This results in this error showing.

My question is.. what do you suggest the most logical solution for pySHACL?

1. Allow string literals without type xsd:anyURI on sh:namespace? (probably the easiest solution)
2. Ignore any sh:declare with prefix sh (because prefix sh: <https://www.w3.org/ns/shacl#> is always present when running SPARQL in PySHACL anyway).
3. When owl:imports https://www.w3.org/ns/shacl silently replace it with a baked-in errata version of the file. (saves on HTTP requests too)
4. Don't allow owl:imports of https://www.w3.org/ns/shacl# from a SHACL Shapes file (probably too strict!)

[HolgerKnublauch]

We have probably made a couple of mistakes in being too strict with datatypes for SHACL itself. For example, many people use xsd:integer values for sh:order although the spec only allows xsd:decimal. I think the proper fix would be to relax the spec in a version 1.1 to allow sh:or. So for sh:namespace you could in principle relax that constraint to allow xsd:string too. You can of course also hard-code an exception for the sh: namespace. In the past I have also redirected owl:imports to local copies, e.g. you can prevent the buggy graph from being downloaded and instead always use your own copy.

[akuckartz]

This section in the W3C Process specification seems to be relevant: https://www.w3.org/2019/Process-20190301/#revised-rec

[ashleysommer]

@HolgerKnublauch
Ok, I've gone with a combination of some of those ideas.

1. if the sh:declare has sh:prefix value of "sh", silently allow string literal for sh:namespace
2. in other cases, still allow string literals for sh:namespace but issue a warning to console
3. bake in a local errata copy of shacl.ttl to use for owl:imports, I was planning to do this anyway