Run CreateAction checks only against the CreateAction(s) that the profile cares about

[elichad]

An RO-Crate conforming to the Five Safes profile may contain additional CreateActions that aren't relevant to the profile (e.g. a CreateAction indicating when the crate metadata itself was created, as in this spec example).

In Five Safes Crate, "the CreateAction" refers to the CreateAction representing the requested/executed workflow run. We should select out specifically that CreateAction, and run the existing relevant checks against that one, rather than against all CreateActions.

If there are more than two such actions, the expected behaviour is undefined. Perhaps the profile should specify that clearer.

[elichad]

We can achieve this by defining a custom class, and then changing sh:targetClass on existing checks to use the new class.

To define a custom class, we can copy how ro-crate:RootDataEntity is defined.

1. declare the class in the profile's ontology.ttl file (see example in the base profile)
2. use a validator:HiddenShape to select the relevant entities and add triples to the data graph that give the entities the new class. See example for ro-crate:RootDataEntity

Be aware that custom classes are not available to SPARQL queries that are fed into rocrate_entity_mod_sparql (because they get applied before the validator is run) so you need to select the desired entities to edit in a different way (maybe just use the id if it's complex)

[elichad]

As for what should define which CreateAction we select, I propose this as the defining characteristic:

A CreateAction with an instrument that matches the mainEntity of the RDE.

[EttoreM]

As for what should define which CreateAction we select, I propose this as the defining characteristic:

A CreateAction with an instrument that matches the mainEntity of the RDE.

@elichad

If we have a way to select the CreateAction we are interested in, why do we need to define a new class? It would be enough to add that condition ("CreateAction with an instrument that matches the mainEntity of the RDE") to select the correct target in the relevant SHACL code. Am I missing anything?

[elichad]

@EttoreM if there's a few checks that use the same complex target, then using a class helps a bit with human-readability and maintainability (if the definition changes in future there's only one place to update it). If there's only one or two checks that use this target, then using a class probably isn't worth it.

(apologies if this has double posted, bad wifi)