Background current situation
- Currently the "Description" consists of one or several text fields with html-based rendering. But it is not documented in Edmond help, when more then one field make sense (and which consequences it has).
- In most datasets, the description field is rather short and in plaintext, like a paper abstract (or shorter). But there are also datasets with a long description and using html formatting features
- On datacite, this formatting is not interpreted, instead the plain text containing the html tags is shown. Example: Edmond dataset and its presentation in DataCite
Proposals
Following proposals are not finally discussed.
P1: Abstract and Description
- Make only one field called "Abstract", being a plaintext field
- Make one (or several?) field called "Description" with html-interpretation
- Send only the "Abstract" field to DataCite as abstract.
Questions and Problems with that proposal:
- How to deal with existing datasets? Would their current "Description" be called "Abstract" now?
- And what would happen with their formatting if already existing?
P2: Description1 as abstract
- Like P1, but:
- Keep the "Abstract" field as html for backward compatibility, but do not use html elements in future in that field
Questions and Problems with that proposal:
P3: No changes in Dataverse fields
- Keep Description fields as they are
- Use the first field for abstract information, thus using no html elements
- Use 2nd field (and maybe more?) for further description, also with html where appropriate
- Sent only first field to DataCite - possible?
Questions and Problems with that proposal:
- How to deal with
&<> characters in the abstract? As long as it is html-interpreted, those need to be escaped (e.g. &, but when escaping, those escape characters are shown in DataCite.
P4: Abstract and Description, Modifying existing datasets
- Like P1, but with following treatment of existing datasets:
- Create a new dataset version (e.g. 1.1)
- Keep "Description" field(s) as in the previous version
- Fill "Abstract" field based on Description field, but unformatting the text to plaintext
Questions and Problems with that proposal:
- Manual effort and decisions needed for several abstracts, where the unformatting would lead to information loss or even misleading information.
Background current situation
Proposals
Following proposals are not finally discussed.
P1: Abstract and Description
Questions and Problems with that proposal:
P2: Description1 as abstract
Questions and Problems with that proposal:
P3: No changes in Dataverse fields
Questions and Problems with that proposal:
&<>characters in the abstract? As long as it is html-interpreted, those need to be escaped (e.g.&, but when escaping, those escape characters are shown in DataCite.P4: Abstract and Description, Modifying existing datasets
Questions and Problems with that proposal: