- Table of contents
- Existing Terms
- Problems that occurr when using the existing implementation
Discussion how to handle defined terms in the CDM Library
Ticket with emails Ben - Andreas: #598
|| Class|count|user-defined|ordered|multiple|needed in model|needed where|
|1| Language|485|2|0||DEFAULT is needed||
|5| NomenclaturalStatusType|24|1|1||?|needed in getStatusByAbbrev etc. -> needed by Formatter/CacheStrategy|
|8| NameRelationshipType|10|1-2|1||1|equals and addBasionym();|
|9| TaxonRelationshipType|27|1|1|0|1|Taxon.getTaxonomicChildren, etc.|
|12| NamedAreaType|2|1|0||?|only in TdwgArea.addTdwgArea(NamedArea)|
|13| NamedAreaLevel|9|1|0||?|only in TdwgArea.addTdwgArea(NamedArea)|
|14| NomenclaturalCode|5|0|0||1|getNomenclaturalCode() in TaxonNameBase-derived classes|
|15| Feature|26|3|0||1|in constructor of some DescriptionElementBase classes|
*count: * Number of existing terms in csv files
*user-defined: * necessity to have user defined instances (0: never; 1: very seldom, 2: sometimes, 3: often)
*who: * who may add a new term (list may be incomplete)
*ordered: * The vocabulary is ordered
*multiple: * multiple vocabularies should be allowed (e.g. different NamedArea vocabularies): 0: same vocabulary in all applications; 1: one vocabulary per application; 2: multiple vocabularies per application
*needed in model: * 1 if the 'static' methods are used in other methods in the model, 0 otherwise
*needed where: * description of how the 'static' methods are used
1. Mixed Model¶
Make those terms that need to be updated often and that are not used in the model ordinary classes (saving via @Cascade). No static methods are available for these classes. Instances of the classes may be received via the service layer.
Make those terms that do not need to be updated or need to be updated very seldom and that are used in the model an enum. Extension is only possible via changing the code.
- List of enums:
- List of unclear classes
- Rank (tendency: make it an enum and think later about possibilities to extend it)
- NomenclaturalStatusType ()
- NameRelationshipType (tendency: make it an enum as all other relationships are also enum)
- List of ordinary classes
- all other classes
- Optional: Keep some classes as classes that have to be initialized (see Existing Implementation ). No cascading is realized for these classes to keep objects unique etc.
- Define an interface IDefinedTerm that both implement
- Problems to be solved:
- Representations for the _enum_s
- Vocabularies for enums including different vocabularies for different codes
Discussion on single classes
- Pro enum:
- Domain logic is based on the ranks. E.g. parsers and formatters need to know if a rank is suprageneric, infrageneric, etc. or what abbreviation is used for them in general
- Additions to the vocabulary are expected to be very seldom
- the order for ranks may differ slightly for different application. This applies to old ranks or infra-ranks like tax.infrasp. or tax.infragen.
Possible Solution: Having different vocabularies which store the order separatly like the feature trees. Different vocabularies for the different codes are needed anyway.
static methods do not have to be available before either connecting to the database or using the model in an unpersistent way (e.g. a web-service for parsing names)
- Domain logic is based on them. E.g. parsers and formatters need to know their abbreviated representation
- Additions to the vocabulary are expected to occurr very seldom but wanted by the user (experience from the Berlin Model)
- static methods do not have to be available before either connecting to the database or using the model in an unpersistent way (e.g. a web-service for parsing names)
- Order is not so important (thus implementation as a class easier)
- Pro enum:
- Domain logic is based on them. E.g. TaxonNameBase and TaxonBase have methods like addBasionym or @ nameRelation.equals(NameRelationshipType.BASIONYM()) @
- Additions to the vocabulary are expected to be very seldom and not so urgent
- Other relationship types are also implemented as enums
- Con enum:
- Additions to the vocabulary are expected to occurr although very seldom
- Pro enum:
- More or less needed in constructor of some subclasses of DescriptionElementBase (e.g. Distribution, CommonName )
- Con enum:
- Many terms maybe added, so a pure enum is impossible !!
2. Existing Implementation¶
Keep the defined terms as classes that are not cascaded via @Cascade.
Make the application developer responsible for using and initializing defined terms in the right way (e.g. adding new ranks only when defintely no other application is using the library)
Write a documentation how to use defined terms in the right way
Implement a good working exception handling with meaningful warnings
Problems that occurr when using the existing implementation¶
not all of them are unsolvable
Transient object xxx Exception when creating 2 CdmApplicationControllers in the same JVM (but not at the same time) due to constructor of Distribution which adds a Feature.DISTRIBUTION . The second time hibernate throws the error.
Uninitialized collection exception when saving taxon names due to calling getFullTitleCache which needs the nomenclatural status abbreviation