SHACL syntax validation fails for sh:or with "Value does not have shape shsh:ListShape"

[jaehnigen-kp]

After having issues with trying to import brick.ttl into engines like Stardog I ran brick.ttl (version 1.4.1) through the SHACL shape validator at https://www.itb.ec.europa.eu/shacl/shacl/upload (against the "Core W3C syntax rules"). This reports 160 errors with the message:

Value does not have shape shsh:ListShape
Test: [Value] - [https://brickschema.org/schema/BrickShape#NumericValue]
Location: [Result path] - [http://www.w3.org/ns/shacl#or

This is also an error that the Stardog Studio Text Editor reports and that seems to break the Stardog import.

Further research led me to https://www.w3.org/TR/shacl/#OrConstraintComponent which AFAICT requires a list syntax for the values.

Can you confirm my assumption that this is a bug that should be fixed?

[gtfierro]

Hi @jaehnigen-kp !

Here's what the Turtle serialization of bsh:NumericValue looks like in the latest distribution of Brick:

bsh:NumericValue a rdf:List ;
    rdf:first [ sh:datatype xsd:float ] ;
    rdf:rest ( [ sh:datatype xsd:decimal ] [ sh:datatype xsd:integer ] [ sh:datatype xsd:double ] ) .

I believe this is a valid List per the SHACL list definition (https://www.w3.org/TR/shacl/#dfn-shacl-list). We haven't had any issues with this construct in pySHACL or Topquadrant's SHACL.

I found a definition of shsh:ListShape here and there's nothing obviously wrong to me. I'll poke around and see if I can find why this is raising an error

[jaehnigen-kp]

Hey @gtfierro, for a first step I assumed that the problem is with the sh:or value (should be SHACL list according to https://www.w3.org/TR/shacl/#OrConstraintComponent) not being enclosed in brackets. Therefore I changed all (60) occurances of sh:or bsh:NumericValue ; to sh:or ( bsh:NumericValue ) ; which gave me 60 validation errors less. But I still got 90 errors with the same error message as above. So that seems to not have been the final issue.

What's your recommendation about these kinds of validation errors in general? There seem to be some contradicting validators out there. Do you know about that specific validator? Is there recommended/"definite" one?

[steveraysteveray]

Just jumping in, but I think sh:or expects a list of SHACL shapes. Try

sh:or ( [bsh:NumericValue] )

[steveraysteveray]

Actually, that's not quite right. The [ ] creates an anonymous SHACL shape, but you need a predicate and object inside.

[gtfierro]

If I have sh:or bsh:NumericValue and bsh:NumericValue is defined as I did above (#656 (comment)), doesn't that fulfill the necessary definition?

[steveraysteveray]

I see what you mean...hmm.

[gtfierro]

@jaehnigen-kp I think this might be a bug in Stardog. Chances are (?) they expect the list (the object of sh:or) to be a blank node. However, we re-use the list here in several places so it's represented as a named node. It is possible we could refactor this to use a Nodeshape to contain the sh:or, and just compose that with the shapes that need it. However, without anything more specific in terms of logs, it is hard to know what is going wrong. The other SHACL processors we use have not complained about this construct.

We have had success using:

• the TopQuadrant implementation (pretty fast, but you have to interact in Java or over CLI): https://github.com/TopQuadrant/shacl
• pySHACL (slower, but in Python): https://github.com/RDFLib/pySHACL
• there are others listed here: https://w3c.github.io/data-shapes/data-shapes-test-suite/#implementation-reports

Be aware that you will want to choose implementations that support SHACL-AF: https://www.w3.org/TR/shacl-af/

Let me know if you have any questions!

[jaehnigen-kp]

@gtfierro Please be aware that I was primarily refering to the validator at https://www.itb.ec.europa.eu/shacl/shacl/upload. Have you tried that yourself? The validation results of Stardog were that confusing that I at first wanted to find some easy-to-access validator and thus ended up at the one linked above. I'll get back when I got some more feedback that is worth following up on.

[gtfierro]

Sorry for my confusing reply! I have tried that site, and I have no idea why it is reporting the results it is. As far as I can tell, our list is correctly formatted using SHACL. Do you get any better report results out of Stardog?

[gtfierro]

I sent the https://www.itb.ec.europa.eu/shacl/shacl/upload folks an email to see if they have any idea why that result is being reported

[costas80]

Hi @gtfierro. I'm the team leader of the Interoperability Test Bed, the service that operates the SHACL shape validator at https://www.itb.ec.europa.eu/shacl/shacl/upload. We got your email but I thought it better to continue the discussion here for full visibility.

The validator in fact is a web app built over the TopQuadrant implementation (the validator is also mentioned in the TopQuadrant README as a reference). As such I'm surprised when you say that using the TopQuadrant library doesn't report the same problems. Do you have a simple PoC (e.g. Git repo) you use for the validation that I could use to replicate and compare?

[jaehnigen-kp]

Do you get any better report results out of Stardog?

Unfortunately not, even worse. For now I only have access to Stardog Cloud and that provides only an online editor view for the TTL with some inline error display. I'll try to get some feedback from there as well.

[gtfierro]

Hi @costas80

Here is a short script which downloads the latest Brick and runs it through the TopQuadrant validation. I have not been able to replicate the SHACL error mentioned by @jaehnigen-kp except on the Interop TestBed site. There are a couple errors here but they mostly have to do with missing imports which shouldn't be relevant to the error.

wget https://repo1.maven.org/maven2/org/topbraid/shacl/1.4.3/shacl-1.4.3-bin.zip
unzip shacl-1.4.3-bin.zip
pushd shacl-1.4.3
export SHACLROOT=`pwd`/bin
export PATH=$SHACLROOT:$PATH
chmod +x $SHACLROOT/*.sh
wget https://brickschema.org/schema/1.4.1/Brick.ttl
shaclvalidate.sh -datafile Brick.ttl

[costas80]

Hi @gtfierro

Having looked into this I believe there is a misunderstanding here. When you say that different SHACL processors don't complain about the Brick shapes, this is when you are using the Brick shapes to validate a graph. This is also what you did in the TopQuadrant PoC that you shared:

shaclvalidate.sh -datafile Brick.ttl

What you did here is the same as using our generic RDF validator at https://www.itb.ec.europa.eu/shacl/any/upload, if you supply both for the content to validate and the shapes to use the Brick shapes. The validation report when comparing the TopQuadrant CLI result and our RDF validator are identical which is not surprising given that internally our validator also uses the TopQuadrant implementation (albeit through Java).

This brings me to the initial issue raised by @jaehnigen-kp, who said he used the Brick shapes with our SHACL shape validator at https://www.itb.ec.europa.eu/shacl/shacl/upload with the "Core W3C syntax rules" (note that this is a different validator than the one I mentioned above). This validator does not validate a graph using the Brick shapes; it rather considers the Brick shapes as the input to validate and validates them against the shapes of the configured profiles. The "Core W3C syntax rules" mentioned are the ones listed in https://www.w3.org/TR/shacl/#shacl-shacl in Section C, "SHACL Shapes to Validate Shapes Graphs". If you take the listed shapes from there, save them in say core_shapes.ttl and use them to validate the Brick shapes (shaclvalidate.sh -datafile Brick.ttl -shapesfile core_shapes.ttl), you will see 160 errors exactly as @jaehnigen-kp mentioned, and matching what our SHACL shape validator reports:

  sh:result    [ rdf:type                      sh:ValidationResult;
                 sh:focusNode                  [] ;
                 sh:resultMessage              "Value does not have shape shsh:ListShape";
                 sh:resultPath                 sh:or;
                 sh:resultSeverity             sh:Violation;
                 sh:sourceConstraintComponent  sh:NodeConstraintComponent;
                 sh:sourceShape                _:b0;
                 sh:value                      bsh:NumericValue
               ];

So, to summarise, the issue at hand is that the Brick shapes fail validation against the published core shapes at https://www.w3.org/TR/shacl/#shacl-shacl (irrespective of our validator). You could choose to address this or not in the Brick shapes but at least you should investigate further and see if a fix is needed.

[gtfierro]

Thank you so much! I can reproduce successfully using your directions.

I'm now working with this minimal file which can reproduce the error: https://gist.github.com/gtfierro/382d4055f51798b84d9b464c0b827e58

The error only occurs when https://w3id.org/rec (REC) is imported. Without the import, the SHACL core shapes are satisfied.

I've looked at the REC ontology and it does not use bsh:NumericValue. However, it does import Brick 1.4. I've looked at the Brick 1.4 ontology which REC refers to and run it through the core shapes in isolation. It, too, does not have any issues with the SHACL core shapes.

So , there is something going on with the interactions of the REC import and, possibly, its own import of Brick. I will continue to dig into this but I'm really not sure what the issue could be. Our use SHACL lists seems to be fine.

[gtfierro]

I'm fairly confident this is due to a circular import of Brick through the REC ontology. I will explore a few fixes and see what we can land in the next Brick patch release (1.4.2)

[gtfierro]

@jaehnigen-kp Please take a look at this version of Brick , which I've produced from the build on #661 . This avoids the circular import and seems to pass the SHACL syntax rules. If this works, I'll try to include this in Brick 1.4.2

[jaehnigen-kp]

@gtfierro This version fully validates against the Core W3C rules in @costas80 validator:

I'll see if that also shows improvements in Stardogs validation and be back in a separate issue if there is proper evidence to follow up. Thank you both for your great support, I learned quite a bit in the process!