grant_id should not be required

[briri]

The current schema indicates that grant_id is required but the statuses are: planned, applied, granted and rejected.

It is unlikely that a grant_id would exist when the status is planned, applied or rejected.

[jomtov]

The grant_id is required only if you have a funding-entry (lines 886-975), as far as I discern. Having a funding entry in itself is not required, it is possible to validate perfectly without it. A dataset is a required key, though. But, agreed that within a funding-entry, requiring a grant_id for status planned, applied and rejected does not make sense. Cf. Figshare, where Funding is also not mandatory, neither is grant_id within such an entry, but an "external" special id for the funder-entry, if there is one, is automatically generated anyway by the system. So, maybe the thinking was similar here in the maDMP-schema, that once you have an entry / field for funding, no matter the status, you also need some kind of identifier for it; perhaps it should only be called something else than grant_id, to distinguish it from a such given by the funding agency itself? On the other hand, since the given data-type is just "string" and there is no other constraint on the grant_id value, as far as I can see, presumably, if status is other than granted, you could just enter something completely redundant like NA . [A little later: I see now that both "funder_id" and "grant_id" - both accept empty strings as identifier value, "identifier": "" . This makes them less useful for validation purposes.]

[hmpf]

This might be a matter of what an id is useful for. On one hand, it can be a PID (persistent, useful outside the place it was first defined). On the other, an id can be needed to make a repeated section uniquely referencable within the system, like a primary key in an SQL table. The latter need not be PIDs and need not be shared with anyone. Without something functioning like the latter, the only way to tell apart two datasets is the order they are defined in the json, so: dataset with index 0 vs. dataset with index 1 etc. (You could in fact use that index as an id and thus be explicit about it.)

I think the two uses has been conflated in this standard: you really need the latter type (since the standard does not define that arrays are ordered [though it may be assumed], but the first type can always be added later. This ties into #33 and #34.

[TomMiksa]

I think the cardinality of grant_id should be changed to 0..1. If I recall correctly, in the "project branch" of the specification we wanted to keep the options open.