Manifestation.biblio only fits with Product (literature)/Venue (scholarly journal).

[rduyme]

Manifestation.biblio section only fits with Product (literature)/Venue (scholarly journal).

https://skg-if.github.io/interoperability-framework/docs/research-product.html#manifestations

Not a nice to have change request : this is a constant question of devs, from the "research data" landscape, when opening the manifestation specifications.

Option 1 :

Rename Manifestation.biblio

We need a field name that make sense for all other "Research Product".

https://skg-if.github.io/interoperability-framework/docs/research-product.html#product_type ( literature, research data, research software, other )

proposition : rename "biblio" to "access" ? other name ?

Option 2 : => seems best option for me.

or shall we move the "in" and "hosting_data_source" directly under manifestation ? and then keep the biblio section

Option 3:
No change, we use the "biblio" section for datasets. (I opened the current ticket to really avoid this)

[dgbroeder]

I assume biblio is optional, only used for the manifestation types where it makes sense. For eg. type research data we should invent another object named "data manifest"?
moving "in" or "hosting_..." external to biblio is not necessary, i assume we can have "hosting_..." as part of "data manifest" (as a mandatory attribute)

[rduyme]

Daan, yes it would make sense to invent something similar to "biblio" for dataset like "data manifest", but not the way you suggest.

I think it is more flexible to go to "option 2". Which allows thinking about any possible structure "data manifest", "software manifest"... as an extension first, then included in core
I see Option 2 as a small change, making the core more robust to future additions of manifestation semantics

@andremann @essepuntato ?

PS : Option 3 : Not doing any change now in core will lead to a status quo, with probably, for example OpenAIRE implementing SKG-IF using the "biblio" section for datasets ex: https://explore.openaire.eu/search/dataset?pid=10.15151%2FESRF-DC-1634316333 (this does not make sense for me)

[katja-moilanen]

In manifestation, there also other fields that are probably not perfectly suitable for CESSDA datasets e.g.

type Object (recommended): The type of the manifestation (e.g., preprint). with properties

• class String (recommended): The URL of the class identifying the entity (e.g., in an ontology) describing that type
• labels Object (recommended): the labels describing the type (multiple for multilingualism). The object is a dictionary, the keys represent language codes following ISO 639-1; the special key none is reserved whenever the information about the language is not available or cannot be shared.
• defined_in String (recommended): the URL of the schema of the manifestation type, e.g., a link to the vocabulary of allowed product types.

and

peer review Object (recommended): Whether the manifestation has undergone a peer review. It must be specify only if information about peer reviewing exists. With properties

• status String (mandatory): describe if the manifestation has been already reviewed (i.e. “peer reviewed”) or if it is currently under review (i.e. “under review”).
• description String (recommended): describe the type of peer review that applies, to choose from single-blind peer review, double-blind peer review, open peer review.

When there are already more fields than just those inside biblio that quite likely will not be used for datasets, I think that it is ok to have biblio , too. It is always possible to fill in only information that suits your own use case.

What comes to the properties in and hosting_data_source, I see two options.
First one is to leave the model as it is and fill in only biblio properties in and hosting_data_source for datasets.
And the second option is to change in and hosting_data_source to be properties of the manifestation, if I understood correctly this is considered a bit problematic for literature because biblio is used for forming bibliographic citations especially for journal articles where venue and data source are part of the bibliographic citation. But there is also other information missing from biblio that is needed for formulating bibliographic citation of the manifestation e.g. the title. Therefore it would be possible to move in and hosting_data_source directly inside manifestation.
I think that both of these options work for CESSDA. If I had to choose I would vote for the second option. But also the first one is ok.