ShaclParseException: No sh:path on a property shape

tpluscode commented 6 months ago

Version

4.10

What happened?

When validating SHACL, Jena appears too strict when parsing property shapes, as it requires sh:path in all cases

See https://s.zazuko.com/3rcogrc. It should find a violation where the schema:name is commented out in data graph.

Relevant output and stacktrace

In Jena, using `shacl` CLI:

org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property shape: node=<https://cube.link/shape/ObservationConstraintProperty> sh:property _:B1af3c02cc02fe669e29397afbbf3405c
    at org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:403)
    at org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:327)
    at org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
    at org.apache.jena.shacl.parser.Constraints.parseConstraint(Constraints.java:201)
    at org.apache.jena.shacl.parser.Constraints.lambda$parseConstraints$21(Constraints.java:159)
    at org.apache.jena.mem.ArrayBunch$2.forEachRemaining(ArrayBunch.java:129)
    at org.apache.jena.util.iterator.WrappedIterator.forEachRemaining(WrappedIterator.java:113)
    at org.apache.jena.mem.TrackingTripleIterator.forEachRemaining(TrackingTripleIterator.java:58)
    at org.apache.jena.shacl.parser.Constraints.parseConstraints(Constraints.java:150)
    at org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:319)
    at org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
    at org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:409)
    at org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:327)
    at org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
    at org.apache.jena.shacl.parser.ShapesParser.parseShape(ShapesParser.java:236)
    at org.apache.jena.shacl.parser.ShapesParser.parseShapeAcc(ShapesParser.java:221)
    at org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:163)
    at org.apache.jena.shacl.parser.ShapesParser.parseProcess(ShapesParser.java:100)
    at org.apache.jena.shacl.Shapes.parseProcess(Shapes.java:111)
    at org.apache.jena.shacl.Shapes.parseAll(Shapes.java:106)
    at org.apache.jena.shacl.Shapes.parse(Shapes.java:83)
    at org.apache.jena.shacl.validation.ShaclPlainValidator.parse(ShaclPlainValidator.java:38)
    at org.apache.jena.shacl.validation.ShaclPlainValidator.validate(ShaclPlainValidator.java:90)
    at shacl.shacl_validate.exec(shacl_validate.java:124)
    at org.apache.jena.cmd.CmdMain.mainMethod(CmdMain.java:87)
    at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:56)
    at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:43)
    at shacl.shacl_validate.main(shacl_validate.java:60)
    at shacl.shacl.main(shacl.java:75)



### Are you interested in making a pull request?

None

afs commented 6 months ago

https://www.w3.org/TR/shacl/#property-shapes

A property shape is a shape in the shapes graph that is the subject of a triple that has sh:path as its predicate.

A property shape must have an sh:path.

The stacktrace is at parse time. Line 25 (which should be indented?) has sh:property with no sh:path. The sh:or, each with a sh:path does not fulfil the definition.

Maybe sh:or should be on the node shape by removing the sh:property (line 25) and its closing ]?

tpluscode commented 6 months ago

From that same paragraph, the next sentence:

A shape has at most one value for sh:path

I thought this meant that it's fine without sh:path. For comparison, here's the same example running Top Quadrant's engine: https://s.zazuko.com/2KuNiJa

I would like to hear @holgerknublauch's opinon. From what I understand, the shapes from the sh:or are merged in runtime, forming a valid property shape effectively. Parse time would too early to determine correctness of such a shape

Maybe sh:or should be on the node shape by removing the sh:property (line 25) and its closing ]?

This my actually work. I always forget that skipping sh:property altogether is also valid in some scenarios

afs commented 6 months ago

That text isn't wrong but it does not override or modify the previous text. "Exactly one" would be better. Elsewhere it says

Each value of sh:property in a shape must be a well-formed property shape.

If the code walks from the target start point it is encountered as a node shape. I can't see text that then makes the sh:or apply because it is not attached to the node shape (obviously, the code is interpreting sh:property with no sh:path as having no path step).

Jena parses all the shapes, not just reachable ones from targets, or ones encountered while validating the data.of the data.

afs commented 1 month ago

SEMICeu/DCAT-AP has made changes.

apache / jena