PROV-O validation rules have a loophole

[bbartley]

Because SBOL3 introduced the sbol:type field on Activity, this has introduced a loophole in the validation rules as currently written that can break the logical order of design -> build -> test -> learn provenance chains. This affects rules sbol-12908 - 12911. The good news, however, is that fixing the loophole results also results in simple language.

Example:

A prov:Activity with a child prov:Association that has a prov:hadRole property that contains the URI http://sbols.org/v3#design SHOULD NOT have child prov:Usage objects that have prov:hadRole properties that contain the URIs http://sbols.org/v3#build or http://sbols.org/v3#test.

Should be amended as:

A prov:Activity with a type that contains the URI http://sbols.org/v3#design SHOULD NOT have child prov:Usage objects that have prov:hadRole properties that contain the URIs http://sbols.org/v3#build or http://sbols.org/v3#test.

[jakebeal]

I believe that this may be obsolete in my #424 pull request, which makes a similar transformation, but table-based.

[jakebeal]

Now that #424 is merged, is this moot?

[bbartley]

No, I dont think it is