Abstract vs extended description

[DwMpdl]

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 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:

• cf P3

P3: No changes in Dataverse

• 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

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.