This is similar in nature as #248. I put put it up for discussion, although I'm not certain myself, which variant I would prefer.
In #200, I proposed schema extensions to support data publication workflows. This proposal was addressing a particular use case of making curated data publications. It included a new entity FundingReference. But this was formulated in a way that it could only be used in relation with a DataPublication. Now there may be other use cases where funding information may be needed. This could be relevant when simply minting DOIs for investigations rather then making curated data publications. But it may also be useful in general to collect this information already in the user office, when submitting the proposal and store it with the investigation.
So this would amend #200 in storing the FundingReference independently of DataPublication. It would consist of the following classes:
FundingReference
Information about financial support
Constraint: funderName, awardNumber
Relationships:
Card
Class
Field
0,*
InvestigationFunding
investigations
0,*
DataPublicationFunding
publications
Other fields:
Field
Type
funderName
String[255] NOT NULL
funderIdentifier
String[255]
awardNumber
String[255] NOT NULL
awardTitle
String[255]
InvestigationFunding
Relation between an investigation and a funding reference
Constraint: investigation, funding
Relationships:
Card
Class
Field
1,1
Investigation
investigation
1,1
FundingReference
funding
DataPublicationFunding
Relation between an data publication and a funding reference
This is similar in nature as #248. I put put it up for discussion, although I'm not certain myself, which variant I would prefer.
In #200, I proposed schema extensions to support data publication workflows. This proposal was addressing a particular use case of making curated data publications. It included a new entity
FundingReference
. But this was formulated in a way that it could only be used in relation with aDataPublication
. Now there may be other use cases where funding information may be needed. This could be relevant when simply minting DOIs for investigations rather then making curated data publications. But it may also be useful in general to collect this information already in the user office, when submitting the proposal and store it with the investigation.So this would amend #200 in storing the
FundingReference
independently ofDataPublication
. It would consist of the following classes:FundingReference
Information about financial support
Constraint:
funderName
,awardNumber
Relationships:
Other fields:
InvestigationFunding
Relation between an investigation and a funding reference
Constraint:
investigation
,funding
Relationships:
DataPublicationFunding
Relation between an data publication and a funding reference
Constraint:
dataPublication
,funding
Relationships: