Validating files against the wrong SHACL file

[melanieWacker]

I used the validation tool to validate a bf:Work description. By accident, I loaded the wrong Shacl file -- the one for bf:Instance and it validated just fine. I had noticed that once before when I accidentally used the Shacl for the wrong format type. In both cases I noticed simply because I knew that my RDF files SHOULD cause some errors so I looked for the problem. But if I hadn't I would have just assumed that my data is good.

So my question is: When I use the Shacl file for the Instance for a Work, shouldn't it tell me that all kinds of things are missing, such as bf:Instance or bf:Print and the required instance fields? Could we adjust the validation so that it catches such errors?

[melanieWacker]

Email response from Steven: If the SHACL doesn’t have targets that match up with what’s in the data, then it doesn’t assume anything about the data. Maybe we could consider having the validation tool say it was unable to find any descriptions that matched up with the targets defined in the loaded SHACL, and the user should confirm they have the correct SHACL and data loaded.

[jermnelson]

After doing some research and testing, there is a way to add a SHACL rule to validate for the existence of a particular class(es). For example, the following SHACL nodeShape:

<big:Monograph:Work:Exists> a sh:NodeShape ;
    rdfs:label "Ensure Monograph and Text exists" ;
    sh:property [ 
        a sh:PropertyShape ;
        sh:path [ sh:inversePath rdf:type ] ;
        sh:minCount 1 ;
        sh:severity sh:Violation
     ] ;
     sh:targetNode bf:Monograph, bf:Text .

will raise a Violation error if the incoming resource graph doesn't have a resource with both bf:Monograph and bf:Text classes. If a resource only has a bf:Monograph the validation will still fail because it is missing a bf:Text.

In our current DCTap structure, we could automatically generate this existence SHACL rule but we should only do this for the main BIBFRAME classes and not for the secondary nodeShapes in the DCTap file. The easiest approach would be to add a boolean column (maybe mustExist) that would create this rule. If adding a column is not desired, we would need to come up with a set of conditions for creating the existence SHACL rule from the DCTap row values but that may not be possible.

[sfolsom]

@jermnelson nice catch! Just to confirm, with sh:NodeShapes like this, we'd get a report that said no data was found for the particular sh:targetNode classes? It could be ignored if it's a bunch of heterogeneous data and may not have instances of the classes?

[sfolsom]

@jermnelson Is there a need to reflect this in the DCTAP, or is it just a matter of hard coding in the prototype?