task #6258
closedPhycoBank - task #6044: cdm model changes/entensions for algea registry
Add Registration to cdm model
Added by Andreas Kohlbecker over 7 years ago. Updated almost 7 years ago.
100%
Description
For the Algea-Registry the model needs to be extended by a Registration class (for the detailed discussion see #6044)
The class Registration
:
class Registration {
private String(255) identifier;
private String(255) specificIdentifier; //id without http-domain
private org.joda.time.DateTime registrationDate;
private Enum status;
private Institution institution;
private TaxonNameBase name;
private Set<TypeDesignationBase> typeDesignations;
private Set<Registration> blockedBy;
private User submitter;
}
The class will have n-1 relation to TaxonNameBase and an n-m associations to TypeDesignationBase
:
TaxonNameBase [1]-------- \ ----[m] Registration / TypeDesignationBase [n]--
RegistrationStatus
see cdm-vaadin:src/main/java/eu/etaxonomy/cdm/mock/RegistrationStatus.java
public enum RegistrationStatus {
preparation,// A new record which is being edited by the Author
curation, //A record ready for the curator to be validated.
ready, //The record has passed the validation by the curator and is ready for publication.
published, //The name or typification has finally been published.
rejected //The registration has been rejected, the process is aborted and the record is preserved.
}
Related issues
Updated by Andreas Kohlbecker over 7 years ago
- Project changed from PhycoBank to EDIT
- Category set to cdm
- Target version set to Release 4.5
- Severity set to critical
For the Algea-Registry the model needs to be extended by a Registration class (for the detailed discussion see #6044)
The class Registration
:
class Registration {
private String(255) identifier;
private String(255) specificIdentifier; //id without http-domain
private org.joda.time.DateTime registrationDate;
private Enum status;
private Institution institution;
private TaxonNameBase name;
private Set<TypeDesignationBase> typeDesignations;
}
The class will have n-1 relation to TaxonNameBase and an n-m associations to TypeDesignationBase
:
TaxonNameBase [1]-------- \ ----[m] Registration / TypeDesignationBase [n]--
Updated by Andreas Müller over 7 years ago
- Target version changed from Release 4.5 to CDM UML 4.7
Updated by Andreas Müller over 7 years ago
- Related to task #6168: Full registration workflow model added
Updated by Andreas Müller over 7 years ago
We also need a new Enum RegistrationStatus, with instances defined in #6168
Updated by Andreas Müller over 7 years ago
- Status changed from New to In Progress
- Priority changed from New to Highest
Updated by Andreas Kohlbecker about 7 years ago
- Description updated (diff)
A registration in progress can be dependant on another registration which needs to be completed before it is possible to advance.
Therefore the Registration class should be extended to be able to reflect this dependency. I suggest adding a Collection field:
private Set<Registration> dependsOn;
Updated by Andreas Kohlbecker about 7 years ago
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.
Updated by Andreas Müller about 7 years ago
- Description updated (diff)
Andreas Kohlbecker wrote:
A registration in progress can be dependant on another registration which needs to be completed before it is possible to advance.
Therefore the Registration class should be extended to be able to reflect this dependency. I suggest adding a Collection field:private Set<Registration> dependsOn;
We decided to call it blockedBy, not dependsOn
Updated by Andreas Kohlbecker about 7 years ago
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
Updated by Andreas Müller about 7 years ago
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 toUser
, 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.
Updated by Andreas Kohlbecker about 7 years ago
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.
Updated by Andreas Müller about 7 years ago
- Description updated (diff)
Andreas Kohlbecker wrote:
Andreas Müller wrote:
Maybe submitter is better than originator.
Yes I agree, if WHK also agrees we can fix this. Already changed the label in the above description.
Updated by Andreas Kohlbecker about 7 years ago
[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
Updated by Andreas Kohlbecker about 7 years ago
Also submittedBy?
Alle einverstanden?
Updated by Andreas Müller about 7 years ago
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.
Updated by Andreas Müller about 7 years ago
Can you please add the Enum states required for the status?
Is it ok to call the enum class RegistrationStatus?
Updated by Andreas Müller about 7 years ago
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.
Updated by Andreas Müller about 7 years ago
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
Updated by Andreas Müller about 7 years ago
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?
Updated by Andreas Kohlbecker about 7 years ago
A Registration without a state makes not much sense. A new Registration should have the state preparation`.
The states are listed in #6168
Updated by Andreas Kohlbecker about 7 years ago
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
Updated by Andreas Kohlbecker about 7 years ago
- Description updated (diff)
Andreas Müller wrote:
Can you please add the Enum states required for the status?
Is it ok to call the enum class RegistrationStatus?
The enum states are now added to the issue description. The enum already exists in the source code, see cdm-vaadin:src/main/java/eu/etaxonomy/cdm/mock/RegistrationStatus.java
Updated by Andreas Kohlbecker about 7 years ago
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
Updated by Andreas Kohlbecker about 7 years ago
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?
Updated by Andreas Kohlbecker about 7 years ago
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
Updated by Andreas Müller about 7 years ago
- Related to task #6513: RegistrationWorkingSet to be modeled explicitely? added
Updated by Andreas Kohlbecker about 7 years ago
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
Updated by Andreas Kohlbecker about 7 years ago
Rein inhaltlich:
- Ist es wichtig zu unterscheiden, zwischen Registrierungen von neuen Namen und alten Basionymen, die mitregistriert werden.
- Ist es ein Qualitätskriterium, wenn Autoren der Namen auch Submitter des Eintrags sind.
- Später ist dann auch wichtig, ob es sich um einen menschlichen Eintrag oder eine „Maschinenregistrierung“ handelt
Updated by Andreas Kohlbecker about 7 years ago
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
Updated by Andreas Kohlbecker about 7 years ago
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!!!!
Updated by Andreas Müller almost 7 years ago
What class should Registration inherit from? CdmBase, VersionableEntity, AnnotatableEntity, IdentifiableEntity?
Updated by Andreas Müller almost 7 years ago
- Priority changed from New to Highest
Updated by Andreas Kohlbecker almost 7 years ago
Andreas Müller wrote:
What class should Registration inherit from? CdmBase, VersionableEntity, AnnotatableEntity, IdentifiableEntity?
AnnotatableEntity is the right one!
Updated by Andreas Kohlbecker almost 7 years ago
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.
Updated by Andreas Müller almost 7 years ago
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).
Updated by Andreas Müller almost 7 years ago
- Status changed from In Progress to Resolved
- Assignee changed from Andreas Müller to Andreas Kohlbecker
Updated by Andreas Kohlbecker almost 7 years ago
- Precedes task #6612: Implement dao and service class for Registrations added
Updated by Andreas Kohlbecker almost 7 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Kohlbecker to Andreas Müller
when accessing persisted Registration I get this error:
java.lang.IllegalArgumentException: EnumType RegistrationStatus not supported by EnumUserType. at eu.etaxonomy.cdm.hibernate.EnumUserType.nullSafeGet(EnumUserType.java:109) at eu.etaxonomy.cdm.hibernate.EnumUserType.nullSafeGet(EnumUserType.java:1) at org.hibernate.type.CustomType.nullSafeGet(CustomType.java:110) at org.hibernate.type.AbstractType.hydrate(AbstractType.java:85) at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2727) at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1728) at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1654) at org.hibernate.loader.Loader.getRow(Loader.java:1543) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:727) at org.hibernate.loader.Loader.processResultSet(Loader.java:972) at org.hibernate.loader.Loader.doQuery(Loader.java:930) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) at org.hibernate.loader.Loader.doList(Loader.java:2611) at org.hibernate.loader.Loader.doList(Loader.java:2594) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2423) at org.hibernate.loader.Loader.list(Loader.java:2418) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:109) at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1774) at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:363) at eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmEntityDaoBase.list(CdmEntityDaoBase.java:836) at eu.etaxonomy.cdm.persistence.dao.hibernate.common.VersionableDaoBase.list(VersionableDaoBase.java:184) at eu.etaxonomy.cdm.api.service.ServiceBase.list(ServiceBase.java:161)
this happens at:
TransactionStatus tx = repo.startTransaction(true);
List<Registration> allRegs = repo.getRegistrationService().list(null, null, null, null, null);
Updated by Andreas Müller almost 7 years ago
Andreas Kohlbecker wrote:
when accessing persisted Registration I get this error:
should be fixed with 4c8dfa574
Updated by Andreas Müller almost 7 years ago
- Status changed from Feedback to Resolved
- Assignee changed from Andreas Müller to Andreas Kohlbecker
Updated by Andreas Müller almost 7 years ago
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.
Updated by Andreas Kohlbecker almost 7 years ago
- Status changed from Resolved to Closed
Updated by Andreas Kohlbecker over 6 years ago
- Related to bug #6842: NPE in Registration constructor when name is null added