While testing the icat.server snapshot release, I noticed that we missed something: we would also need an email attribute in DataPublicationUser. The reason is the same as for givenName, familyName and affiliations: we may want to include this information in the publication metadata or on the publication landing page, but they are subject to change, so we can't rely on the attributes in User, we need to keep a record of this information at the moment of the publication.
For email, this may be even more critical, this can be illustrated best with an example of a real data publication. On the landing page, the email addresses of two of the authors are exposed to allow for getting into contact with them. It was a conscious decision of the authors in this case to designate the 2nd and the 4th author to serve as a contact for this publication, but not the others. So we'd need a way to store this decision.
While testing the
icat.serversnapshot release, I noticed that we missed something: we would also need anemailattribute inDataPublicationUser. The reason is the same as forgivenName,familyNameandaffiliations: we may want to include this information in the publication metadata or on the publication landing page, but they are subject to change, so we can't rely on the attributes inUser, we need to keep a record of this information at the moment of the publication.For
email, this may be even more critical, this can be illustrated best with an example of a real data publication. On the landing page, the email addresses of two of the authors are exposed to allow for getting into contact with them. It was a conscious decision of the authors in this case to designate the 2nd and the 4th author to serve as a contact for this publication, but not the others. So we'd need a way to store this decision.