| Title (Goal) | Validation only for selected resources |
|---|---|
| Primary Actor | Information architect, developer |
| Scope | Component |
| Level | Summary |
| Author | Stefano Cossu |
| Story (A paragraph or two describing what happens) | Enable mandatory and/or optional content and structural validation only for certain resources |
This use case exemplifies a repository in which validation can be applied to arbitrary resources instead of a whole repository. This validation can consist of mandatory and/or recommended rules, as described in Enforce validation across repository and Optional validation.
Following a discussion on this wiki [1], a hierarchy has been considered a not recommended way to group resources that should or should not be validated. Containment predicates such as ldp:contains or pcdm:hasMember, or assigning RDF types to individual resources to be validated, is a better choice.
Example 1: validate resources under a specific container
- User uploads an image of type cma:Image under /container_a/image1
- User uploads an image of type cma:Image under /container_b/image2
- User uploads an image of types cma:Image and cma:Validatable under /container_b/image3
- /container_a is of type cma:Validatable
- /container_b is not cma:Validatable
- Validation rules are defined for cma:Image in a configuration
- Configuration also indicates that rules should only be checked if the resource is of type cma:Validatable, or is contained by a container of that type
- Validation is checked for /container_a/image1 since it is under a cma:validatable container (i.e. </container_a> ldp:contains </container_a/image1>)
- Validation is not checked for /container_b/image2
- Validation is checked for /container_b/image3 because this resource itself is cma:validatable
Example 2: Indicate conditions for individual rules
A validation configuration specifies that:
- Property myns:uid:
- is mandatory
- Property myns:documentType:
- is mandatory
- must be checked if the resource is of type cma:validatable or is in a container of such type
- Property myns:creator:
- is mandatory
- must be checked if the resource is of type cma:validatable or is in a container of such type
- if validation fails, request should be forwarded to a specified service which forwards the request to Fedora and issues a warning that this property should be present
Given the resources being ingested in Example 1:
- for all three resources, if myns:uid is missing, ingest fails
- for /container_a/image1 and container_b/image3:
- if myns:documentType is missing, ingest fails
- if myns:creator is missing, ingest proceeds and a warning is issued
3 Comments
Stefano Cossu
Aaron Birkland, let me know if these examples reflect your expectations.
Aaron Birkland
It's slightly different from what I was imagining, only in the treatment of myns:uid. I was imagining that cma:validatable would be a marker to "invoke the validation extension here". So if container_b does not have cma:validatable, then there would be no problem ingesting a resource missing myns:uid, as the extension is not involved in the transaction at all. In other words, API-X looks for the presence of cma:validatable to determine if the request should be routed through the validation extension in the first place.
Stefano Cossu
That would work if you want to establish validation on a per-resource (or per-container) basis.
My example is trying to be as flexible as possible by establishing validation on a per-property basis. So if you want myns:uid to be always present, you can do that.
We can discuss whether this fine-grainedness is necessary for the stakeholders.