adding funding to flat data #89

msz · 2025-08-12T17:23:35Z

msz commented

2025-08-12 17:23:35 +00:00

This is an effort parallel to #87, also motivated by inm7/annotate.inm7.de-data#24.

It seems #87 has gained a life on its own, so even though doing things here would lead to (easy) merge conflicts (e.g. in dataset slot assignment / shacl order) it feels preferable to open this new PR here to streamline discussions.

It also seems that this PR might become obsolete due to ongoing development in https://github.com/psychoinformatics-de/datalad-concepts/ (e.g. "flat schema" with a FlatThing), this is useful for me to make sure that I am on the right track regarding the flat schemas overall, and have my reasoning checked.

Here's my reasoning:

We need to add a funding slot to the dataset (to allow funding attribution). It should allow interoperability with two schemas in particular, DataLad-catalog and DataLad-concepts. Here's the information we need to convey:

On one hand, DataLad catalog recognizes three funding properties: name ("of the funding source, such as a funder or grant scheme"), identifier ("of the fund, such as a grant number"), description (free-form).
On the other hand, DataLad concepts has dlres:Grant, which only requires a pid, has one directly defined property (sponsor, range: Agent), and many inherited properties.
Additionally, from knowledge-graph point of view, we should be able to have (externally issued) identifiers - both for the funding institution and for the grant (e.g. ROR and GEPRIS ID respectively for DFG and its grants).

In summary, based on the above, I want the following properties for a dataset's funding item: name, description, identifier, funder / name, funder / identifier. To get there:

I think I don't want to import dlres:Grant directly (e.g. it would come with range: Agent, something we don't have a notion for), I want to create something "lighter" (right?).
By being a Thing, a newly-defined Grant inherits a description slot. By having a curation aid mixin, it also inherits identifiers. I need to add name and funder. It's probably reasonable to make these two slots required.
It seems fair to narrow down the range of a funder to an Organization, which flat-data schema imports from flat-base, and call the slot funding_organization. The Organization already has a name (direct) and identifiers (from CurationAid) which checks our boxes.

This is an effort parallel to #87, also motivated by https://hub.psychoinformatics.de/inm7/annotate.inm7.de-data/issues/24. It seems #87 has gained a life on its own, so even though doing things here would lead to (easy) merge conflicts (e.g. in dataset slot assignment / shacl order) it feels preferable to open this new PR here to streamline discussions. It also seems that this PR might become obsolete due to ongoing development in https://github.com/psychoinformatics-de/datalad-concepts/ (e.g. "flat schema" with a FlatThing), this is useful for me to make sure that I am on the right track regarding the flat schemas overall, and have my reasoning checked. Here's my reasoning: We need to add a funding slot to the dataset (to allow funding attribution). It should allow interoperability with two schemas in particular, DataLad-catalog and DataLad-concepts. Here's the information we need to convey: - On one hand, DataLad catalog recognizes three funding properties: `name` ("of the funding source, such as a funder or grant scheme"), `identifier` ("of the fund, such as a grant number"), `description` (free-form). - On the other hand, DataLad concepts has [dlres:Grant](https://concepts.datalad.org/s/resources/unreleased/Grant/), which only requires a `pid`, has one directly defined property (`sponsor`, range: `Agent`), and many inherited properties. - Additionally, from knowledge-graph point of view, we should be able to have (externally issued) identifiers - both for the funding institution and for the grant (e.g. ROR and GEPRIS ID respectively for DFG and its grants). In summary, based on the above, I want the following properties for a dataset's funding item: `name`, `description`, `identifier`, `funder / name`, `funder / identifier`. To get there: - I think I don't want to import `dlres:Grant` directly (e.g. it would come with range: Agent, something we don't have a notion for), I want to create something "lighter" (right?). - By being a Thing, a newly-defined Grant inherits a description slot. By having a curation aid mixin, it also inherits identifiers. I need to add name and funder. It's probably reasonable to make these two slots required. - It seems fair to narrow down the range of a funder to an Organization, which flat-data schema imports from flat-base, and call the slot `funding_organization`. The Organization already has a name (direct) and identifiers (from `CurationAid`) which checks our boxes.

msz force-pushed grant from 37215cc0e6

Codespell / Check for spelling errors (pull_request) Successful in 26s

Details

Model checks / lint (pull_request) Failing after 1m27s

Details

Validate examples and verify unmodified conversion / lint (pull_request) Successful in 2m55s

Details

to 38aa80653a

Codespell / Check for spelling errors (pull_request) Successful in 20s

Details

Model checks / lint (pull_request) Successful in 1m54s

Details

Validate examples and verify unmodified conversion / lint (pull_request) Successful in 3m21s

Details

2025-08-13 17:30:16 +00:00

Compare

msz changed title from ~~WIP: adding funding to flat data~~ to adding funding to flat data

2025-08-13 17:33:15 +00:00

mih reviewed

2025-08-14 11:29:57 +00:00

src/flat-data/unreleased.yaml

					
				@ -127,0 +136,4 @@

				      Source of funding (such as a specific grant). Used for funding

				      acknowledgements.

				    range: Grant

				    multivalued: true

FTR: I am including this funding_sources as funding in the resource-mixin schema over at datalad-concepts.

FTR: I am including this `funding_sources` as `funding` in the `resource-mixin` schema over at datalad-concepts.

Codespell / Check for spelling errors (pull_request) Successful in 20s

Details

Model checks / lint (pull_request) Successful in 1m54s

Details

Validate examples and verify unmodified conversion / lint (pull_request) Successful in 3m21s

Details

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin grant:grant

git switch grant

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main

git merge --no-ff grant

git switch grant

git rebase main

git switch main

git merge --ff-only grant

git switch grant

git rebase main

git switch main

git merge --no-ff grant

git switch main

git merge --squash grant