remove `owl:imports sh:` from examples

[VladimirAlexiev]

https://w3c.github.io/data-shapes/shacl/#sparql-prefixes gives an example with owl:imports sh: ;
Others copy this example, eg in the electrical CIM/CGMES.

• as explained in SHACL: do not import sh: Sveino/Inst4CIM-KG#157, I see no reason to import sh: in SHACL files.
• whereas it's hurtful in SHACL-SHACL validation, as discussed in by default do not owl:import in the Data Graph ISAITB/shacl-validator#15

[HolgerKnublauch]

The example uses owl:imports sh: because by doing so the intent was to illustrate (transitive) reuse of the sh:prefix declarations found in the sh.ttl - see the sh:declare in the beginning of https://github.com/w3c/data-shapes/blob/gh-pages/shacl/shacl.ttl

So this is completely intentional and remains desirable here, but does not say anything about whether this is a general suggestion for non-SPARQL use cases.

The way we have solved the issue with redundant validation in TopBraid is to have a flag to "ignore system shapes". I suggest most SHACL engines should have such a flag because they cannot anticipate whether some input graph does eventually owl:import it (or shsh:).

[VladimirAlexiev]

reuse of the sh:prefix declarations

They only declare sh. Maybe it's better to mandate that engines should predefine this prefix?

"ignore system shapes"

Which are they, only sh, shsh? How about dash or anything else that may come out of SHACL Profiles work?

issue with redundant validation

• When validating SHACL as data, we clarified that import should be ignored: clarify that owl:import is not enacted for the Data Graph #241.
  So I'm inclined to close this issue as invalid.
• The question is whether SHACL authors will find useful shapes (or components) to reuse in sh, shsh, dash?

[HolgerKnublauch]

Ignoring system shapes in TopBraid looks like this

https://github.com/TopQuadrant/shacl/blob/master/src/main/java/org/topbraid/shacl/engine/filters/ExcludeMetaShapesFilter.java

where

	ExcludeMetaShapesFilter.addSystemShapes(GRAPHQL.InputObjectType, GRAPHQL.InputType, GRAPHQL.InputValue, GRAPHQL.JSON2RDFTestCase, GRAPHQL.ListType, GRAPHQL.MutationTestCase, 
			GRAPHQL.NameShape, GRAPHQL.NamedType, GRAPHQL.NodeShapeShape, GRAPHQL.NonNullType, GRAPHQL.Query, GRAPHQL.QueryTestCase, GRAPHQL.ScalarType, GRAPHQL.WriterTestCase);

So we have excluded a list of well-known shapes that would validate classes, shapes etc. Therefore, when a data graph includes ontology and shape definitions, no time is wasted on them.

[HolgerKnublauch]

@VladimirAlexiev can this issue be closed? I think I have answered your questions.

On predefining certain prefixes such as sh: we have #176

[VladimirAlexiev]

If #176 is accepted then there is no reason to import sh, so this issue should be implemented

[HolgerKnublauch]

I have closed #176 because I see no easy way forward, and I also would like to close this ticket here.

Both need to be addressed through education and training material. A previous commit had already marked the owl:imports triple as Optional, which I believe addresses the main concern here.

@VladimirAlexiev please reopen this ticket if you disagree.