Conversation
douglowe
left a comment
There was a problem hiding this comment.
I've had a read of Eli's original issue, and I think I understand now what we're doing (I didn't before - which I think may have led me to think we were doing something different here).
Many of the changes look sensible to me, and should do what we want. I've a couple of changes I'd request though.
- Should we use
five-safes-crate:WorkflowRuninstead ofro-crate:WorkflowRun? - We should be able to transform the RDF graph once, and then use the
ro-crate:WorkflowRuntag in all our tests after that. Can you create a 0_workflowrun.ttl file in the 'must' folder, which contains only this transformation - perhaps that would work? - Should we be mentioning WorkflowRun in the message strings which tests return? If this is an internal tag then will this confuse users?
rocrate_validator/profiles/five-safes-crate/may/11_workflow_execution_phase.ttl
Outdated
Show resolved
Hide resolved
alexhambley
left a comment
There was a problem hiding this comment.
Happy with this I think, just a bit concerned about the maintainability of the duplicated code block across the rules. :)
rocrate_validator/profiles/five-safes-crate/may/11_workflow_execution_phase.ttl
Outdated
Show resolved
Hide resolved
|
OK, I managed to centralise the Also made the dependency on the RO-Crate root explicit: |
tests/integration/profiles/five-safes-crate/test_5src_7_requesting_workflow_run.py
Show resolved
Hide resolved
tests/integration/profiles/five-safes-crate/test_5src_7_requesting_workflow_run.py
Show resolved
Hide resolved
rocrate_validator/profiles/five-safes-crate/must/11_workflow_execution_phase.ttl
Outdated
Show resolved
Hide resolved
douglowe
left a comment
There was a problem hiding this comment.
Thanks for merging the definition into one file - that looks good.
Can you review the messages that rules return, as well as the tests you've removed? I think we should make sure that the messages that the end user gets mention CreateAction not WorkflowRun.
|
@elichad & @alexhambley - I've finished off the last couple of message strings for Ettore, as he's on leave now. If you're okay with the PR now I'll merge it. |
| """ ; | ||
| sh:message "`CreateAction` --> `instrument` MUST reference the same entity as `Root Data Entity` --> `mainEntity`" ; | ||
| ] ; | ||
| sh:message "The crate MUST contain at least one `CreateAction` (corresponding to the workflow run)" ; |
There was a problem hiding this comment.
This message could be clearer about how the user can resolve the issue - combine the new message with the old message?
| """ ; | ||
| sh:message "Each `object` in `CreateAction` MUST reference an existing entity." ; | ||
| ] . No newline at end of file | ||
| sh:message "Each `object` in the `CreateAction` entity corresponding to the workflow run MUST reference an existing entity." ; |
There was a problem hiding this comment.
| sh:message "Each `object` in the `CreateAction` entity corresponding to the workflow run MUST reference an existing entity." ; | |
| sh:message "In the `CreateAction` entity corresponding to the workflow run, each `object` MUST reference an existing entity." ; |
| """ ; | ||
| sh:severity sh:Warning ; | ||
| sh:message "RootDataEntity SHOULD mention workflow execution object (typed CreateAction)." ; | ||
| sh:message "RootDataEntity SHOULD mention a workflow run object (typed CreateAction)." ; |
There was a problem hiding this comment.
| sh:message "RootDataEntity SHOULD mention a workflow run object (typed CreateAction)." ; | |
| sh:message "RootDataEntity SHOULD reference a workflow run entity (typed CreateAction) through `mentions`." ; |
There was a problem hiding this comment.
after making this comment I just noticed there's a very similar message in some of our tests - https://github.com/eScienceLab/rocrate-validator/pull/104/changes#diff-ddb895f3dbdf2ce99bcefe65919fb782c019baca128c2410f57823c73c8f84a9R88 - do we have two tests doing the same thing?
| sh:severity sh:Warning ; | ||
| sh:message "The agent of a CreateAction entity SHOULD have an affiliation" ; | ||
| ] . No newline at end of file | ||
| sh:message "The agent of the `CreateAction` corresponding to the workflowrun SHOULD have an affiliation" ; |
There was a problem hiding this comment.
| sh:message "The agent of the `CreateAction` corresponding to the workflowrun SHOULD have an affiliation" ; | |
| sh:message "The agent of the `CreateAction` corresponding to the workflow run SHOULD have an affiliation" ; |
|
|
||
|
|
||
| ro-crate:FindRootDataEntity a sh:NodeShape, validator:HiddenShape; | ||
| sh:order 0 ; |
There was a problem hiding this comment.
I don't think sh:order does anything for us here. From https://www.w3.org/TR/shacl/#order (emphasis added):
Property shapes may have one value for the property sh:order to indicate the relative order of the property shape for purposes such as form building. The values of sh:order are decimals. sh:order is not used for validation purposes and may be used with any type of subjects. If present at property shapes, the recommended use of sh:order is to sort the property shapes in an ascending order, for example so that properties with smaller order are placed above (or to the left) of properties with larger order.
| # # ################################################################# | ||
|
|
||
| # Declare a WorkflowRun class | ||
| ro-crate:WorkflowRun rdf:type owl:Class ; |
There was a problem hiding this comment.
might be too late for this, but I think a slightly preferable name for this class would be WorkflowRunAction - signifying to devs that it's a subclass of Action.
|
|
||
|
|
||
| ro-crate:FindWorkflowRunAction a sh:NodeShape, validator:HiddenShape; | ||
| sh:order 1 ; |
Closes #43.
This PR implements a solution for treating the workflow-execution
CreateActionas a dedicatedro-crate:WorkflowRunentity across the Five Safes SHACL profiles.At a high level:
A hidden SHACL rule was added to the relevant TTL files to infer the triple
CreateAction -> rdf:type -> ro-crate:WorkflowRunfor theCreateActionwhoseinstrumentmatchesRootDataEntity -> mainEntity.All SHACL constraints that are really about the actual workflow run were then retargeted from generic
CreateActiontoWorkflowRun, with corresponding updates on shapes' names and messages.Tests were updated accordingly.
One important testing detail:
In the Python tests, the graph mutations still target entities of type
CreateAction, notWorkflowRun.This is intentional:
WorkflowRunis inferred by SHACL during validation, so it is safer for the tests to alter the sourceCreateActionnodes in the RO-Crate metadata graph.This remains correct as long as the tests are understood to target the specific
CreateActionthat is effectively the workflow run, and not any otherCreateActionthat may also be present in the crate.A separate consistency note:
prefixes.ttl, the RO-Crate namespace is exposed in SPARQL viarocrate(without the dash), while elsewhere in the codebase we also usero-crate.This did not originate in this PR, but it is something we may want to clean up in future to align prefix syntax across the codebase.