EDIT

We also need a new Enum RegistrationStatus, with instances defined in #6168

We need to be able to associate Registrations with Users and CRUD of Registrations need to be controlled via GrantedAuthorities. Therefore the Registration needs to be sub class of CdmBase.

Andreas Kohlbecker wrote:

We need to be able to associate Registrations with Users and CRUD of Registrations need to be controlled via GrantedAuthorities. Therefore the Registration needs to be sub class of CdmBase.

In a follow up discussion on the above considerations we concluded that the Registration should have an association to User, so that the person being responsible for the registration is clearly related to the registration. Naming suggestions for this property:

• editor
• author
• originator
• initiator

Andreas Kohlbecker wrote:

Andreas Kohlbecker wrote:

We need to be able to associate Registrations with Users and CRUD of Registrations need to be controlled via GrantedAuthorities. Therefore the Registration needs to be sub class of CdmBase.

In a follow up discussion on the above considerations we concluded that the Registration should have an association to User, so that the person being responsible for the registration is clearly related to the registration. Naming suggestions for this property:

• editor
• author
• originator
• initiator

Can you please define semantics of the new attribute a bit more. Is the person the one who "applied" for the new name or is it the person who works on the registration process (in this case usually WHK). The translations I found for originator http://dict.leo.org/englisch-deutsch/originator do not make this clear (it is both "Antragsteller" and "Bearbeiter"). Therefore this term might not be the best.

Andreas Müller wrote:

Can you please define semantics of the new attribute a bit more. Is the person the one who "applied" for the new name or is it the person who works on the registration process (in this case usually WHK). The translations I found for originator http://dict.leo.org/englisch-deutsch/originator do not make this clear (it is both "Antragsteller" and "Bearbeiter"). Therefore this term might not be the best.

This is the person who initiated the registration process. This is either the author (or one of a team) of the according publication or someone who is doing a post publication registration on behalf of the actual author. I would not use the verb "apply" in this context. I think talking of submissions is more appropriate, since this is also what is happening at the publishers side. The author submits the publication of a new name and it submits in the same sense the data for registration. WHK is only the person doing the data curation. Data curation is a manual validation of the data entered of the submitter . A data curator is not working on the registration process.

Maybe submitter is better than originator.

[Henning wrote]

Hallo Andreas,

ich habe grundsätzlich immer Schwierigkeiten mit solchen Substantiven.

Erst nach Leo-Befragung, kann ich mich dem „originator“ halbwegs anschließen, nach LEO passt das sogar besser. In bezug auf diese ganzen Substantive des Englischen habe ich überhaupt kein Spachgefühl. [Provider würde hier wegen des Gebrauchs in der GBIF-Welt nicht passen]

Echte Frage: Warum denn nicht einfach „ProvidedBy“ oder „SubmittedBy“ ? [originated by würde schon wieder schlechter passen]

Viele Grüße,
Henning

Also submittedBy?

Alle einverstanden?

ist mein Favorit, Henning

it is a bit against our CDM conventions. At other places we say collector and not collected by, or combinationAuthor not xxxBy, etc. The only by that we use is createdBy and updatedBy for the first and the last user who worked on a record.

But if you prefer submittedBy I can live with it.

Can you please add the Enum states required for the status?

Is it ok to call the enum class RegistrationStatus?

Should submitted(By) really be of type "User", not of type Person, Team or Agent? Is it always necessary that a submitter has access rights? Currently a User can only be Person, so this prevents teams or institutions to become submitters.

Can you please add information about bidirectionality.

So, should a name link to it's registrations (probably yes)
Should a submitter link to it's registrations (probably no),
...

For all bidirectional relationships please add the name and type of the attribute at the other side (e.g

Set<Registration> registrations 

in TaxonNameBase

Andreas Müller wrote:

Can you please add the Enum states required for the status?

Is it ok to call the enum class RegistrationStatus?

What should be the default state? Or is NULL allowed and the default?

A Registration without a state makes not much sense. A new Registration should have the state preparation`.
The states are listed in #6168

Andreas Kohlbecker wrote:

A Registration without a state makes not much sense. A new Registration should have the state preparation.
preparation will therefore the default State.
The states are listed in #6168

Andreas Müller wrote:

it is a bit against our CDM conventions. At other places we say collector and not collected by, or combinationAuthor not xxxBy, etc. The only by that we use is createdBy and updatedBy for the first and the last user who worked on a record.

But if you prefer submittedBy I can live with it.
The votes for this decision are:

• AM: +1 for submitter
• AK: +1 for submitter
• WHK: +1 for submittedBy

So it is 2:1 for submitter. Consistency in the model naming convention is important, for the UI we always can change the 'submitter' into 'submittedBy'. Therefore let's name it submitter

Andreas Müller wrote:

Can you please add information about bidirectionality.

So, should a name link to it's registrations (probably yes)
Should a submitter link to it's registrations (probably no),
...

For all bidirectional relationships please add the name and type of the attribute at the other side (e.g

Set<Registration> registrations 

in TaxonNameBase

• name: should link to its Registration
• submitter: I think that we don't need a back reference here
• typeDesignation: since the name links to its Registration the typeDesignation also should

Does everybody agree?

Andreas Müller wrote:

Should submitted(By) really be of type "User", not of type Person, Team or Agent? Is it always necessary that a submitter has access rights? Currently a User can only be Person, so this prevents teams or institutions to become submitters.

Ich denke, dass Agent die besser Wahl wäre. Damit wären wir am flexibelsten. Andererseits würde dadurch aber auch das "Einsammeln" der Registrierungen für einen Nutzer aufwändiger da zwei Fälle berücksichtigt werden müssen:

User->Person->Registration
User->Person->Team->Registration

Andreas

Ja, das wäre ein bisschen aufwendiger. Aber sicherlich lösbar. Ein bisschen schwieriger ist der Fall bei Institutionen. Da ist der Zusammenhang zum User ja noch unschärfer.
Aber auch das wäre lösbar denke ich.

Grundsätzlich stellt sich aber vor allem die Frage, welches die Hauptgründe sind, warum wir überhaupt einen Submitter brauchen.
Geht es v.a. darum anzuzeigen, wenn ich eingeloggt bin, wie es meinen Registrierungen geht oder geht es darum, der Außenwelt etwas über den Submitter der Registrierung was zu erzählen. Wenn nur ersteres, wäre „User“ richtig, wenn auch Zweiteres wichtig, dann halte ich Agent für sinniger.

AM

Rein inhaltlich:

1. Ist es wichtig zu unterscheiden, zwischen Registrierungen von neuen Namen und alten Basionymen, die mitregistriert werden.
2. Ist es ein Qualitätskriterium, wenn Autoren der Namen auch Submitter des Eintrags sind.
3. Später ist dann auch wichtig, ob es sich um einen menschlichen Eintrag oder eine „Maschinenregistrierung“ handelt

Aus technischer und organisatorischer Sicht ist der Submitter vor allem wichtig um die Registrierungen die zu einem User gehören herausfiltern zu können.
Die Berechtigungen sind in dieser Situation irrelevant. Es geht hierbei nur um die Zuordnung. Der Submitter wird in den meisten Fällen auch immer der Creator sein, es sei denn eine Registrierung wird auf einen anderen User übertragen, weil einer der Autoren eines Teams die Durchführung der Registrierung an jemand andren abgibt.
Die Basis einer jeden Registrierung ist immer eine Publikation, also entweder die nomenklatorische Referenz des neuen Namens oder die 'citation' der TypeDesignation. Falls eine Registrierung mehrere TypeDesignations umfasst müssen alle die selbe citation und citationMicroreference haben. Über diese 'Referenzen' besteht schon eine Relation zu dem Autor/AutorenTeam. Bei post-publication Registrierungen aber wird der Submitter/User in vielen Fällen nicht dem Autorenteam angehören. Wir brauchen also auf jeden Fall eine separate Relation zu der Person, welche die Registrierung aktuell bearbeitet. Hier stellt sich die Frage ob das nicht auch mehrere Personen sein können? Sollten wir den Fall berücksichtigen, dass es ein Team also mehrere Personen geben kann, die gemeinsam die Registrierung bearbeiten? Bei Massenpublikationen von vielen Namen in ein und der selben Publikation ist es durchaus vorstellbar, dass das Team sich die Arbeit teilen möchte. In diesem Fall gäbe es mehrere User.

Es gibt in CDM-Java gesprochen also folgende Möglichkeiten:

A) Set<User> submitters;

oder

B) User submitter;

oder

C) Agent submitter;

Mit scheint (A) mittlerweile am sinnvollsten zu sein.

Andreas

Nach abschließender Diskussion mit Henning ist klar geworden, dass der Fall mehrerer User eigentlich irrelevant ist. Wir können davon ausgehen dass es immer nur ein User sein wird der sich um die Registrierung aller Namen und Typen in einer Publikation kümmert. Sollte der Fall auftreten, dass ein Team gemeinsam die Registrierungen bearbeiten will muss sich das Team einen Useraccount anlegen dessen Credentials dem gesamten Team bekannt gemacht werden so dass alle zugriff haben. Übrigens wollen

Publisher auch immer mit genau einer Person, dem Corresponding Author kommunizieren.

Also: "The winner is ...."

User submitter;

Ta da da daaaaaaa!!!!

What class should Registration inherit from? CdmBase, VersionableEntity, AnnotatableEntity, IdentifiableEntity?

Andreas Müller wrote:

What class should Registration inherit from? CdmBase, VersionableEntity, AnnotatableEntity, IdentifiableEntity?

AnnotatableEntity is the right one!

After the discussion this week I am thinking about renaming the Registration class to NomenclaturalAct, this term would be less application purpose oriented an the more correct term from the process in the scientific process.

I think NomenclaturalAct is a broader term then Registration. It is also valid for existing NomenclaturalActs in published publications which are obviously not covered by the current class while many attributes of the class are not usefull for existing Nomenclatural acts (specificIdentifier, Identifier, Institution, maybe even status).

Andreas Kohlbecker wrote:

when accessing persisted Registration I get this error:

should be fixed with 4c8dfa574

Andreas Müller wrote:

Andreas Kohlbecker wrote:

when accessing persisted Registration I get this error:

should be fixed with 4c8dfa574

But be careful, there are new model changes. Need to run update script from scratch.

can this be closed?