using sh:class and sh:targetClass

[elf-pavlik]

I would like to discuss it initially without taking about SKOS, later we can discuss those topic together in appropriate issues.
Currently all shapes use sh:targetClass ( -> in compact syntax), in #19 I also started using sh:class (in compact e.g. ex:hasDependencyOn IRI ex:Software).

Looking at https://www.w3.org/TR/shacl12-core/#ClassConstraintComponent

The condition specified by sh:class is that each value node is a SHACL instance of a given type.

and the snippet, I understand that it ensures that in case of ex:hasDependencyOn IRI ex:Software the values will always need to by typed as ex:Software. This way stating <https://sai.js.org/vuejectron> ex:hasDependencyOn cdata:Jeff_Zucker would be invalid since Jeff is typed as a ex:Person but not as a ex:Software.

Looking at https://www.w3.org/TR/shacl12-core/#targetClass

If s is a shape in a shapes graph SG and s has value c for sh:targetClass in SG then the set of SHACL instances of c in a data graph DG is a target from DG for s in SG.

TBH I have hard time parsing that definition but I understand that each instance of a class becomes focus node for that shape. This would probably help us with #12

Since we already have all the shapes using sh:tragetClass, should we also add sh:class wherever they are missing in current shapes?

@jeswr I believe we will need your arcane knowledge of SHACL here 🧙‍♂️

[jeswr]

sh:targetClass is not a validating constraint - it is one of the targets declarations used to say "all instances of this class should be validated against this constraint" - there may also be cases where something that is not an instance of that class should also be validated against that constraint.

E.g. you could have a constraint which is

ex:EntityConstraint a sh:NodeShape ;
  sh:targetClass ex:Person ;
  sh:targetClass ex:Organisation ;

So all people and organisations must be validated against the constraint; but we don't want to enforce that everything being validated must be both a person and organisation.

sh:class on the other hand is used to say "everything being validated against this constraint MUST be an instance of this class."

[elf-pavlik]

"all instances of this class should be validated against this constraint"

Maybe before we discuss if using sh:class makes sense for us we should talk about adding rdf:type constraints. If we want to use class-based targets, shouldn't we have something like rdf:type [1..1] in=[ex:Person] in our shapes? I guess we would need this approach:

• Handling a complex set of constraints w3c/data-shapes#398

If we don't require types to be asserted, how do we expect to use them for targeting?

• Validate data using GH actions #12

[jeff-zucker]

I note that @jeswr's recent wip for SHACL validation comments out the SolidResourceShape. I recognize that it was just a stub and should be fleshed out with something similar to w3c/data-shapes#398 as @elf-pavlik mentions above.

In my opinion the shape needs to ensure that all SolidResources have one type in the set of top-level types, may have additional types that are not top-level types, and must have one or more of what we are calling ex:subType values from the list of subTypes in the shapes. I used sh:targetSubjectsOf rdf:type but this is probably wrong since not everything that has an rdf:type is a SolidResource. Probably all catalog entries that are SolidResources should have that as type e.g. <#mediaKraken> a ex:SolidResource, ex:Software; ex:subType con:LeisureActivityApp and the SolidResourceShape should target that class.

A SolidResource, in my mind is a tangible thing, something or someone that a person or software can use or work in conjunction with. OTOH, something like a keyword is an intangible and even if we eventually give it a type, it is not a SolidResource, it is a way of categorizing Solid Resources.