Should we add `Journal`, `JournalArticle` and related

jsheunis commented

2025-06-03 11:00:55 +00:00

Owner

For when we want to describe how a dataset is published or referenced in journal articles, or whichever outlet. These aspects were modeled in the (now deprecated?) simple-submit schema: https://hub.psychoinformatics.de/inm7/inm7-concepts/src/branch/main/src/simpleinput/unreleased.yaml#L782-L864

Are similar classes intentionally not included in the flat-data schema? If so, for which reason. If not, any arguments against porting them into the flat-data schema? Or into flat-base?

For when we want to describe how a dataset is published or referenced in journal articles, or whichever outlet. These aspects were modeled in the (now deprecated?) simple-submit schema: https://hub.psychoinformatics.de/inm7/inm7-concepts/src/branch/main/src/simpleinput/unreleased.yaml#L782-L864 Are similar classes intentionally not included in the `flat-data` schema? If so, for which reason. If not, any arguments against porting them into the `flat-data` schema? Or into `flat-base`?

mih commented

2025-06-03 14:23:05 +00:00

Owner

They will (have to) come

mih commented

2025-06-04 04:46:06 +00:00

Owner

It could make sense to compartmentalize publication-related classes and slots into a flat-publication component.. The user management app does not need them.

It could make sense to compartmentalize publication-related classes and slots into a `flat-publication` component.. The user management app does not need them.

👍 1

jsheunis referenced this issue

2025-07-18 08:58:03 +00:00

Document datalad-catalog entities not covered by the flat schemas #24

Rows
Columns

Should we add Journal, JournalArticle and related #12

Should we add `Journal`, `JournalArticle` and related #12