Skip to content
This repository has been archived by the owner on Nov 13, 2023. It is now read-only.

Question: what is a LivePaper? #50

Open
stevewds opened this issue Jun 26, 2023 · 4 comments
Open

Question: what is a LivePaper? #50

stevewds opened this issue Jun 26, 2023 · 4 comments

Comments

@stevewds
Copy link

Suppose I want to indicate that a dataset is associated with a publication that is in some stage of production (perhaps a preprint, perhaps accepted to a journal). Would I create a LivePaper object or a ScholarlyArticle?

@lzehl
Copy link
Collaborator

lzehl commented Jun 26, 2023

I would leave it to @apdavison to respond in more detail but here my understanding:

Preprints should have a DOI and can be associated to a DatasetVersion under relatedPublication by linking to a respective DOI object.

For publications that do not yet have a DOI I'm not a 100% sure if a link under relatedPublication to a ScholarlyArticle is correct (since this would still require that the article is already published). @apdavison what do you think ? do we need a modification / extension here for "submitted"/"accepted" publications?

@apdavison
Copy link
Member

I think ScholarlyArticle is fine for preprints that don't have a DOI. You would just leave the "isPartOf" field empty, or identify the preprint server using Periodical. If accepted, then you would set "isPartOf" to a PublicationVolume with "volumeNumber" set to " accepted" or "in press".

(to answer the question in the title, a "live paper" is an interactive, web-based document that embeds research products such as datasets, models, code within it - see https://www.ebrains.eu/data/live-papers/live-papers for an example of how these are used in EBRAINS)

@stevewds
Copy link
Author

stevewds commented Jul 3, 2023

Thanks.

It seems that the "isPartOf" field is required, so one wouldn't be able to leave it empty, right? I wonder if it make sense to allow "isPartOf" to be optional?

While I'm making suggestions :-) , I hope it's okay to make another. Right now, to specify a ScholarlyArticle, one has to specify a volume or issue object and then the periodical. It seems burdensome even when the information is available, and sometimes the information isn't available for some periodicals that aren't organized in volumes and issues (like some electronic publications, like biorxiv or eLife). What about having a "Periodical" field with volume or issue parameters as optional for the ScholarlyArticle field?

Steve

@lzehl
Copy link
Collaborator

lzehl commented Sep 15, 2023

@stevewds Thanks a lot for this feedback. I think we will not change the requirements for ScholarlyArticle. But your needs trigger for sure a reevaluation of the metadata model.

For the preprint / "isPartOf" issue: A preprint that does not have a DOI and is not submitted / belongs to any journal / preprint-archive should then probably just be registered as a WebResource (if it is accessible through a URL) or registered entirely differently. @apdavison maybe a specific schema for preprints ?

For the periodical issue: I think volumes and issues are important metadata for ScholarlyArticles. I would not like to introduce short cuts into the metadata model that allow just to skip this information. From a curation point of view I would always request to provide the full information (especially they are typically easy to access through the citation tools / options from the periodicals. However we need to consider all use cases. Even though eLife articles do not have a publication issue, they are associated to a publication volume (as far as I know). For biorxiv you are fully correct as far as I know they do not have issues or volumes. This brings us back to the question if preprints should be handled in separate schemas. Another option a bit different to your approach: we add Periodical as other linked type to the property "isPartOf" in ScholarlyArticle.

@apdavison what do you think?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants