Some time ago, when implementing foreign keys (and primary keys) from spec, the relevant frictionless libraries hadn't fully implemented validation by foreign keys.
It's worth looking at where this is and replace equivalent function in Data Curator (1 less part to maintain).
Also align naming of primaryKey (in DC property name is primaryKeys). For keeping up with changes to what is available in schema, it is simpler to iterate properties from frictionless without having to know what they are, rather than explicitly naming them every time we export (atm Import does exactly this ie: it doesn't name these, it just defers to frictionless for these to populate DC store- so removes the need to keep up-to-date with any new schema property additions/changes as it will always come from their schema (published under 'lib' atm in relevant library as json)
Some time ago, when implementing foreign keys (and primary keys) from spec, the relevant frictionless libraries hadn't fully implemented validation by foreign keys. It's worth looking at where this is and replace equivalent function in Data Curator (1 less part to maintain). Also align naming of primaryKey (in DC property name is primaryKeys). For keeping up with changes to what is available in schema, it is simpler to iterate properties from frictionless without having to know what they are, rather than explicitly naming them every time we export (atm Import does exactly this ie: it doesn't name these, it just defers to frictionless for these to populate DC store- so removes the need to keep up-to-date with any new schema property additions/changes as it will always come from their schema (published under 'lib' atm in relevant library as json)