Authors of reference.json

[sthhher]

Should be givenName, surname and contact_id treated as arrays or as strings? Authors is obvious that is an array, but the attributes of them?

[jlgelpi]

Keep it simple. I would keep an author as an object with single GivenName (String), and single Surname (String), Initials could be either deduced from GivenName (to allow to change the display format if needed) of included explicitly. Allow for "Jr." middle names, etc.

[redmitry]

According the json schema it is "authors" : [{"givenName": "name", "surname": "surname", "contact_id": "contact_id"}, {}, {}]. IMHO this may be improved in 2.0 - "contact_id" refers to the Contact list. Contacts already have givenName and surename properties.

[jlgelpi]

Not all authors in a reference will have a OEB contact_id

[redmitry]

Indeed, but may be defined as oneOf {"givenName", "surename"} or {"contact_id"}. Now "givenName" and "surename" are required.

[jmfernandez]

Answering to @redmitry

Indeed, but may be defined as oneOf {"givenName", "surename"} or {"contact_id"}. Now "givenName" and "surename" are required.

the given name and surname of the author should always be including, as it should be the one appearing in the original bibliographic reference.

So, it makes lots of sense to have either:

• A required string for the literal author line in the manuscript's authorship, or
• Two required string fields, one for the first + middle name and another for the last name.

and the contact_id is veeeeeeeeery optional, added only for future cross-referencing platform authors to their related community or tool manuscripts (like it happens in ResearchGate, for instance).

[jmfernandez]

The decision is just fusing both givenName and surname into publishName, replacing the optional reference to Contact by an optional field to store the ORCID. Also, a new issue should be open to deal with the separation of Contact and Contributor, as @sthhher and @Gabriel-Vergely have suggested and analyzed.

[jmfernandez]

Fixed