EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852010-07-07T11:55:14ZEDIT Project Management
Redmine feature request #1872 (In Progress): CICHORIEAE additional text to descriptive datahttps://dev.e-taxonomy.eu/redmine/issues/18722010-07-07T11:55:14ZRalf Hand
<p>Descriptive data sections in the editor (e.g. distribution, common names) generally should have possibilities to add additonal free text. Currently, distribution is limited to the TDWG unit system.</p>
<p>In case that text is added it should be displayed under the heading, i.e. Distribution starting with text, then map, then TDWG list and so on.</p>
bug #1866 (New): BookDefaultCacheStrategy does not show free text date publishedhttps://dev.e-taxonomy.eu/redmine/issues/18662010-07-06T16:16:15ZAndreas Müller
<p>In general the free text field in time period needs a clear definition.</p>
<p>Usually the year fields should not be empty. But if they are the Book cache strategy (and maybe some others) do not return any date. This is probably not intended behaviour.</p>
<p>Also see comment in testGetTitleCache in BookDefaultCacheStrategyTest</p>
bug #1835 (New): PALMS. Not clear format for authors and references to be parsed correctlyhttps://dev.e-taxonomy.eu/redmine/issues/18352010-06-25T13:21:15ZSoraya Villalba
<p>For a name like Geonoma awaensis A.J.Hend., Borchs. & Balslev, Britoonia 60: 190 (2008), the author team is not parsed properly (A.J.Hend. is taken as part of the only author and Borchs. & Balslev are parsed as part of the reference.</p>
<p>Also, the reference is underlined in yellow and there is a message saying The name has problems. detail or year part ambiguos. I don't see what's wrong with it.</p>
feature request #1742 (New): Adapt the ZooNameDefaultCacheStrategyhttps://dev.e-taxonomy.eu/redmine/issues/17422010-05-19T11:44:40ZKatja Luther
<p>For zoological names the cachestrategy should be adapted. For example mostly the markers for infrageneric or infraspecific names are not shown in the name.</p>
<p>Every change also needs to be reflected in the according parser.</p>
<p>see cichorieae Sprint branch r9033</p>
bug #1660 (New): [BLOCKED][NameRelations] No distinction between zool. and bot. code in name rela...https://dev.e-taxonomy.eu/redmine/issues/16602010-04-27T15:43:22ZNiels Hoffmann
<p>[BLOCKED][NameRelations] No distinction between zool. and bot. code in name relation's labels</p>
feature request #1176 (New): OriginalSource has to support multiple OriginalNameshttps://dev.e-taxonomy.eu/redmine/issues/11762009-10-14T14:01:58ZNiels Hoffmann
<p>It has to be possible to enter multiple OriginalSource entries (see <a class="issue tracker-5 status-5 priority-15 priority-high11 closed" title="feature request: Model changes for references, taxonBase, OriginalSource (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/1080">#1080</a> first comment). As I understood it, it also has to be possible to associate multiple Names with an OriginalSource.</p>
<p><a class="issue tracker-5 status-5 priority-15 priority-high11 closed" title="feature request: Model changes for references, taxonBase, OriginalSource (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/1080">#1080</a> suggests to handle the names through originalNameString from ReferencedEntityBase, but I don't know if that is correct. Eckhard stated today, that there may be multiple names and do we really want to enter them as a string and not link to an actual name object?</p>
<p>see also #1232</p>
feature request #1097 (New): Check comb. nov. with taxonomistshttps://dev.e-taxonomy.eu/redmine/issues/10972009-09-23T10:25:30ZAndreas Müller
<p>Ben:</p>
<p>Appended phrase makes sense, but we don't use this right now. I wonder if it also might be the place (in time) for e.g. comb. nov., sp. nov., syn. nov., stat. nov. etc which don't really belong to the name, as things are not always "nov", but users might want to mark a taxon as "comb. nov." but then remove this status after a period of time.</p>
feature request #786 (New): Write Developers Guide for CDM Libraryhttps://dev.e-taxonomy.eu/redmine/issues/7862009-06-10T15:04:00ZAndreas Müller
<p>Write Developers Guide for CDM Library</p>
feature request #718 (New): Long term solution for saving images to taxahttps://dev.e-taxonomy.eu/redmine/issues/7182009-04-29T08:59:40ZNiels Hoffmann
<p>The quickFix introduced with #700 is not a long term solution.</p>
feature request #674 (New): Turn off all concept-related functionality in the Editor in Preferenceshttps://dev.e-taxonomy.eu/redmine/issues/6742009-04-03T13:39:41ZPepe Ciardelli
<p>Suggestion from Bill and Soraya at Kew - March 24, 2009</p>
bug #597 (In Progress): DefinedTerm problem solvedhttps://dev.e-taxonomy.eu/redmine/issues/5972009-02-12T11:19:37ZAndreas Müller
<p>Having extendable defined terms that can be used flexible even in a none persistent environment and with a default initialization is more or less impossible.</p>
<p>A solution must be found using e.g. a mixed model for defined terms. </p>
<p>see <a class="wiki-page" href="https://dev.e-taxonomy.eu/redmine/projects/edit/wiki/DefinedTerms">DefinedTerms</a></p>
<hr>
<p>Dear Ben, all, </p>
<p>Thank you very much for your long and comprehensive answer.</p>
<p>Yes, I think you are right that 1) and 2) are more or less contradiction or need an extreme effort to implement.<br>
So after a long time of scratching my head and being reluctant I started to adopt the idea of enumerations for some classes.<br>
I put up a wiki site ( <a class="wiki-page" href="https://dev.e-taxonomy.eu/redmine/projects/edit/wiki/DefinedTerms">DefinedTerms</a> ) to collect some useful information and to continue the discussion about which class should be implemented which way.<br>
At the moment it looks to me, that there are mainly 4 or 5 classes to be implemented as enum.<br>
2 or 3 classes still unclear or implemented with initialization and static methods (or something similar) All the rest implemented as ordinary classes with cascading etc.</p>
<p>The most critical classes are Rank and NomenclaturalStatusType I think as they are not so easily made enumerations but at the same time needed for the domain logic.</p>
<p>I already started to implement NomenclaturalCode as an enum to gain some experience. For this I created an interface IDefinedTerm that is supposed to be implemented by all the defined term class types.<br>
I think I will continue to implement one of the relationships to get some more experience. </p>
<p>Thinks we have to clarify are at least:</p>
<p>1) How to handle vocabularies for the enum classes<br>
2) How to handle representations for the enum classes<br>
3) How to access the ordinary classes via the API<br>
4) How to make clear that also the ordinary class instances should be reused whenever possible<br>
5) How to handle Ranks and NomenclaturalStatusTypes ..</p>
<p>I hope all this will help to resolve the existing problems.</p>
<p>Cheers,<br>
Andreas</p>
<hr>
<p>Hi Andreas,</p>
<p>I guess I wanted to de-couple term initialization from the terms themselves, as this tight coupling ties the term entities to a particular term loading implementation, and also leads to circular dependencies between spring-managed beans and hibernate entities. By allowing terms to initialize themselves, it is much harder to de-couple the term initialization from the terms themselves (and from spring, hibernate etc).</p>
<p>I think that there are some options here, but each solve a different problem. So I just want to take a step back and make sure that I understand what the requirements are here:</p>
<p>1) That term vocabularies have certain (pseudo) static members which are always available, and behave</p>
<p>as though they were immutable, static instances.</p>
<p>2) That term vocabularies are extendable at runtime, and can be re-ordered, added to, and changed</p>
<p>3) That these members are available (almost) as soon as an application is started</p>
<p>4) That if a database exists, these default terms are persisted in the database and available for use (these</p>
<p>terms should not need to be persisted explicitly, they should just <u>be_there</u> in the database).</p>
<p>5) That terms have multi-lingual representations</p>
<p>6) That the terms are easy to use (i.e. can be used without an explicit initialization step).</p>
<p>Its worth pointing out here that requirements (1) and (2) directly conflict with each other. Normally, it would be an either-or situation, where data types would meet requirement 1, or requirement 2, not both. I think that it is more-or-less impossible to meet both requirements in a satisfactory way. Add Spring and hibernate to the mix, and you've got a very complex situation.</p>
<p>Anyway, following on from this, I think that we have some potential solutions ranging from a proximate fix which might help some tests pass, to a more ultimate fix, which might make it easier to work with the defined terms more generally.</p>
<p>1) In terms of fixing your current applications, you can apply your fix, but I am concerned that this will remove the ability to specify how terms are loaded. Currently, you have three options:</p>
<p>DefaultTermInitializer - initializes terms from files. That's it.</p>
<p>PersistentTermIntitializer - initializes terms from files, and persists them into the database if they are not there already TestingTermInitializer - puts a set of terms into the database, and loads the terms from that set.</p>
<p>In addition, if you allow terms to auto-initialize, then I'm sure you will run into problems of terms being initialized by hibernate as part of the construction of the SessionFactory prior to other beans and services (such as the transaction manager) being created, problems related to injecting spring components into data entities, circular dependencies between spring beans and data entities, problems with controlling the order in which terms are initialized etc. Also I think that because the methods must be static, one of the implementations must be chosen over the others, which makes it hard / impossible to substitute another term initialize.</p>
<p>So my preference is not to follow this route. My gut feeling is that it will lead to hard-to-solve problems throughout the CDM, especially once you try to scale the application across multiple users with multiple JVMs, or single web applications that are clustered, or whatever. Thinking laterally, the current implementation, which is based on static variables is already a "bad code smell" (<a href="http://en.wikipedia.org/wiki/Code_smell">http://en.wikipedia.org/wiki/Code_smell</a>) as these static variables will be shared across multiple threads. In a multi-threaded application, what happens when one thread adds a term to an ordered vocabulary and re-orders the terms, whilst another thread uses those terms? (I'm developing a migraine just thinking about it!)</p>
<p>2) I think that a second solution is to re-examine the requirements for defined terms. I don't know what the answers are, but the questions are:</p>
<p>1) Is pseudo-static behaviour more important than runtime extensibility, or vice versa?</p>
<p>2) Is the relative importance of the two main requirements the same for all types of defined term?</p>
<p>My feeling is that the answer to question 2 is no. You can see this from the way in which different term classes are used. For example, NomenclaturalCode is never going to be extended during the lifetime of the CDM (unless java still exists at the point where we discover extra-terrestrials ;-), Language is not going to be extended, it seems to me that Rank is not going to be extended very often if at all, and a lot of logic is based upon it.</p>
<p>Feature, on the other hand, is likely to be extended, as is State, Scope, Modifier, MarkerType. NamedArea is another likely candidate, where you might have several vocabularies.</p>
<p>So my suggestion is that: If it is more important that a class is extensible, then we should use java Classes, and instances (i.e. the current DefinedTermBase implementation), and avoid using static member fields. This will impose restrictions on the way which those vocabularies are used, but given that they are mutable, it is probably a bad idea to base logic in the CDM on the existence and state of specific instances of those changeable terms as we can't really guarantee what the vocabulary is going to be like at runtime. i.e. At runtime there might be 2 named area vocabularies, or six or one. It is probably a bad idea to have behaviour related a specific named area vocabulary, like "English Counties" or "TDWG areas" in a generic NamedAreaService, given that sometimes, the named areas won't belong to that specific vocabulary, or might have extra members, or members which have been changed.</p>
<p>If it is more important that the class is static, then we should use Java enumerations, and benefit from immutability, global static members across JVMs, no need to persist (and therefore no need to do something clever when starting up the application), the ability to query by value without needing a join (i.e. such terms would be attributes, not foreign keys in related entities). This would also provide a level of stability for some of the parser / cache strategy implementations, I think, as the set of NomenclaturalCode, Rank, etc would be restricted, so application developers can't supply new ranks which are unknown to the parser / strategy generator. It would also mean that these enums could be used throughout the CDM without worrying about transactions / lazy initialization / spring etc. etc. It would also be thread-safe.</p>
<p>Anyway, I appreciate that this isn't really a proper answer to your question, but I'm worried that making small changes to the DefinedTermBase / term initialization design is unlikely to address the fundamental problem, which is that the design is driven by two requirements which conflict with each other. I don't think it is necessarily a failure as a software developer to pick one requirement over the other. Maybe taking some time now to think about the problem again can help avoid problems later.</p>
<p>Cheers,</p>
<p>Ben</p>
<p>++++++++++++++++</p>
<p>From: Müller, Andreas</p>
<p>Sent: Tuesday, February 10, 2009 4:56 PM</p>
<p>Subject: [dev-cdmlib] term init again</p>
<p>Hi Ben,</p>
<p>We just tested some of the new functionality you added to the Library for the term initialization and run into some kind of problem.</p>
<p>As you may remember you added to e.g. RankTest the following lines:</p>
<pre>@BeforeClass
public static void setUp() {
DefaultTermInitializer vocabularyStore = new DefaultTermInitializer();
vocabularyStore.initialize();
}
</pre>
<p>So you explicitly force the user to initialize the terms by hand. For sure this is a good way to force the user to think about what terms he is using. On the other hand it is something I would like to avoid as it needs more explanation how to use the library. Actually the little import applications that we have in app-import did not run anymore because before we did not have any kind of initialization (e.g. the SalvadorActivator in the berlinModel package does have the following line</p>
<pre>static final NomenclaturalCode nomenclaturalCode = NomenclaturalCode.ICBN();
</pre>
<p>that returns a null object the way it is implemented now.</p>
<p>So I wonder if we could change this by implementing a generic method that calls the DefaultTermInitializer if no initialization has been done yet. E.g.:</p>
<pre> protected static Map<UUID, NomenclaturalCode> termMap = null;
protected static NomenclaturalCode getTermByUuid(UUID uuid){
if (termMap == null){
DefaultTermInitializer vocabularyStore = new DefaultTermInitializer();
vocabularyStore.initialize();
}
return termMap.get(uuid);
}
</pre>
<p>The TermMap could be filled by setDefaultTerms</p>
<pre> @Override
protected void setDefaultTerms(TermVocabulary<NomenclaturalCode> termVocabulary) {
termMap = new HashMap<UUID, NomenclaturalCode>();
termMap.put(uuidIcbn, termVocabulary.findTermByUuid(NomenclaturalCode.uuidIcbn));
..
</pre>
<p>//also a loop over termVocabulary.getTerms is possible or even better as you do not have to copy uuids at all</p>
<p>This is kind of one step back in direction of the old implementation so I would like to ask you if you this is in some way against the ideas when you refactored the term initialization.</p>
<p>For me there are 2 cons of the implementation:</p>
<p>1) It needs a bit more space, as you store not only the terms but also the Map. But I think we can live with this.</p>
<p>2) It may cause any kind hibernate problems because of duplicate objects that I can not predict yet.</p>
<p>The pros are:</p>
<p>1) You can use the library without any active initialazation</p>
<p>2) You can run the Initialization for each class separately, so not all classes have to be initialized if they are not needed. This needs some further refactoring and does not allow testing for existence on application start-up.</p>
<p>3) It reduces the code as lines like:</p>
<pre>private static NomenclaturalCode ICZN;
</pre>
<p>are not necessary anymore.</p>
<p>Also the lines in setDefaultTerms() can be deleted (see comment in the code above)</p>
<p>What do you think?</p>
<p>Cheers,</p>
<p>Andreas M.</p>
task #578 (In Progress): @Ignore removed from PersistentTermInitializerTesthttps://dev.e-taxonomy.eu/redmine/issues/5782009-02-05T10:57:22ZAndreas Müller
<p>Hi Ben,</p>
<p>Yes probably you right. I didn't really go into the PersistentTermInitializerTest problem but tried it within eclipse with the new override.properties and it worked whereas in maven it doesn't </p>
<p>Caused by: java.lang.ClassCastException: org.hibernate.collection.PersistentSet cannot be cast to java.util.SortedSet</p>
<pre> at eu.etaxonomy.cdm.model.common.OrderedTermVocabulary.addTerm(OrderedTermVocabulary.java:154)
at eu.etaxonomy.cdm.model.common.OrderedTermVocabulary.addTerm(OrderedTermVocabulary.java:1)
at eu.etaxonomy.cdm.database.PersistentTermInitializer.firstPass(PersistentTermInitializer.java:141)
at eu.etaxonomy.cdm.database.PersistentTermInitializer.initialize(PersistentTermInitializer.java:87)
</pre>
<p>I will leave the test as @Ignored for now.</p>
<p>Cheers,</p>
<p>Andreas</p>
<p>----Ursprüngliche Nachricht-----</p>
<p>Von: Ben Clark <a href="mailto:B.Clark@kew.org">B.Clark@kew.org</a> </p>
<p>Gesendet: Donnerstag, 5. Februar 2009 11:07</p>
<p>An: '<a href="mailto:dev-cdmlib@mnhn.fr">dev-cdmlib@mnhn.fr</a>'</p>
<p>Betreff: RE: [dev-cdmlib] I want to commit some major changes to cdmlib term loading, please could you confirm that this is ok?</p>
<p>Hi Andreas,</p>
<blockquote>
<p>For PersistentTermInitializerTest I had to create a new override.properties because for this test it looks like > we need term initializing. Or do I think the wrong way here?</p>
</blockquote>
<p>I'm not sure what to do about PersistentTermInitializerTest, really, as running it side-by-side with the other tests (which use testing term initializer) results in some issues. I think disabling it using override.properties simply checks against the terms initialized by TestingTermInitializer, not actually testing the PersistentTermInitializer at all.</p>
<p>I just @Ignore -ed it, not a perfect solution, but the whole term initialization scenario is quite complex and I couldn't think of a better idea. Running the other tests properly is more of a priority, I think.</p>
<p>Cheers,</p>
<pre> Ben
</pre> task #488 (Feedback): Parser for editor documentedhttps://dev.e-taxonomy.eu/redmine/issues/4882009-01-22T13:50:45ZAndreas Müller
<p>Marc G: Einige Anmerkungen zum Editor nach einem Gespräch mit unserem Pariser Gast:</p>
<p>In der Dokumentation des Editors sollte stehen welche "Formate" für Referenzen geparst werden</p>
<p>====</p>
<p>Meeting 2022-03-18 (<a href="https://wiki.bgbm.org/bdinotes/index.php?title=BDI_332):">https://wiki.bgbm.org/bdinotes/index.php?title=BDI_332):</a></p>
<p>parser documentation needs to be extracted (AM) and included in current documentation (WGB)</p>
feature request #461 (In Progress): Improve / compact display of typeshttps://dev.e-taxonomy.eu/redmine/issues/4612008-12-15T09:40:22ZAndreas Kohlbecker
<p>The display of types in the dataportal is redundant and should be more compact. A general solution should be flexible enough in order to respect different needs.</p>
<p>From 3.2.2009 to 5.2.2009 different type formating rules have been discussed by email. This conversation is reproduced below using trac ticket comments.</p>
feature request #424 (New): Implement advanced searchhttps://dev.e-taxonomy.eu/redmine/issues/4242008-10-15T09:29:33ZNiels Hoffmann
<p>Exemplar groups asked for a more sophisticated search form that would make it possible to search for additional criteria.</p>
<p>This would include:</p>
<ol>
<li><del>Filters on the regular name search (e.g. accepted only)</del></li>
<li><p><del>FullText search of features and their description elements, either over all features or by feature explicitly</del>: #2942 & #476</p></li>
<li><p>search for references on one or more taxa <a class="wiki-page new" href="https://dev.e-taxonomy.eu/redmine/projects/edit/wiki/Irina">Mi 18.02.2009</a> </p>
<ol>
<li>separate citations concerning nomenclatural acts from other citations ("If the database can separate citations concerning nomenclatural acts from other citations, it would enrich the search.") <a class="wiki-page new" href="https://dev.e-taxonomy.eu/redmine/projects/edit/wiki/Irina">Mi 18.02.2009</a> </li>
</ol></li>
<li><p><del>search for misapplied names (optional)</del> - fixed: #2648</p></li>
<li><p>search for Orthographic variants ( NameRelationship ) see (<a href="http://dev.e-taxonomy.eu/dataportal/cyprus/?q=cdm_dataportal/taxon/2b532496-49e1-44bd-a6f9-66a0b0cb7fd4/synonymy">http://dev.e-taxonomy.eu/dataportal/cyprus/?q=cdm_dataportal/taxon/2b532496-49e1-44bd-a6f9-66a0b0cb7fd4/synonymy</a>)</p></li>
<li><p>taxonnomic filter, which allows to limit the search to a subtree of the classification</p></li>
</ol>
<p><del>see also #2432 (geographic filter)</del></p>