Strange use of sh:or for targetClass declarations in SHACL shapes

[labra]

@jesswr pointed me to the catalog shape that appears here and I think the use of sh:or to declare optional target class declarations is not currently supported in SHACL.

I mean, this pattern:

:SolidProjectResourceShape a sh:NodeShape ;
 sh:or (
   [ sh:targetClass soar:PodService ]
   [ sh:targetClass schema:LearningResource ]
 );
 . . .

which probably means that :SolidProjectResourceShape can be applied to either soar:PodService or schema:LearningResource or any other element in that list does not work in SHACL as far as I know.

I think a simpler way to declare it would just be:

:SolidProjectResourceShape a sh:NodeShape ;
 sh:targetClass soar:PodService, schema:LearningResource, ...
 . . .

[jeswr]

I agree, and have been working on an alternate version of this shape at https://github.com/jeswr/solid-catalog/blob/main/shapes/catalog.shc which I will contribute shortly.

[jeswr]

which I will contribute shortly.

Doubt I will be able to come to it for at least a month so don't be worried about stepping on my toes if you get to it first @jeff-zucker

[jeff-zucker]

@labra - Yes, I agree, my first pass at a SHACL shape for the catalog needs much work. I think your suggestion to turn it into a simple list will work for now. I was aiming for something I still do not how to accomplish in SHACL so am open to ideas. I want to be able to define a generalized catalog-record shape and then have specific additional properties for the various target classes. If anyone can point me to some examples or writing about this kind of subclassing withing SHACL, I'd appreciate it.

[jeswr]

https://www.w3.org/TR/shacl/#AndConstraintComponent is what you're after.

Only downside is that devtools like LDO tend to not be designed for logical constraints.