EDIT

Hi all,

the ReferencePropertyDefinitions would also be useful for the taxeditor to unclutter ReferenceDetailElement.createControls(...) and other related code. (see #7479)

Andreas

Now that the fields are switched visible and unvisible it turns out that this can cause layout problems. These need to be solved before this issue can be closed.

except of the institution, organization and school fields which are handled in #7480 all issues named in this ticket should be fixed. There are furthermore some fields which need further discussion, but this is a topic for the cdm in general and should not block us from closing this issue. A new ticket should be opened if needed.

Some notes on the above:

DOIs: are available but just not implemented yet #3767

Date published for Journals and Printseries: Date published is NOT meant for the runtime but for an exact date when a publication was published or a period if this date can not be defined exactly. I do not see the necessity of having a "runtime" attribtue but if needed we should use another attribute due to the different semantics. But as we are not a reference managing tool I think there is no need for this.
The methods will be removed from the according interfaces.

Journals Authors: not needed, I agree, will be removed from the interface

Book Series: (Discuss: isn’t In-reference the right place to store and select a series, rather than in a string?): often you only have information like "ser. 2". The CDM philosophy is that a book should always be a possible endpoint in the reference hierarchy holding all informations needed for correct formatting. PrintSeries might only be an additional possiblity to group books together. This is also for performance reaons as otherwise you may need to initialize up to 4 references to format a single reference.

Editor: ok (discuss: person/team atomized?): this is under discussion in CDM, not yet sure if it will be implemented, but maybe it will

ISBN: correct handling of multiple ISBN definetly needs further discussion as references may have multiple ISBN, and especially the ISBN for the e-Version is an important issue

Print Series - Edition : Not needed, can be handled via title as print series is anyway only meant for grouping publications and not for formatting.

Uri: currently available for most types but will be removed in future except for websites (and maybe databases). Links to online available references should not be stored in URI but in the new "ExternalLink" which will be related as a collection of external links available for this publication. This is because there might be multiple links available for the same reference and it also allows a description what exactly stands the link for. Currently this is already available for the OriginalSource class to link to sources (e.g. single pages in a reference).

InProceedings - Series: Correct, that this is not needed. Also it is not available in the IInProceedings interface so I wonder how it made it's way into the TaxEditor. Please remove.

Proceedings - ISBN: correct, this is missing as proceedings are not inheriting from IBook though they are mostly books, I added ISBN to IProceedings

PrintSeries - Nomenclatural title: not necessarily needed for formatting, but nice to have; it is already available in IPrintSeries via inheritence from IReference, so we should implement it in TaxEditor

PrintSeries - authors: rejected, this is not needed and may lead to confusion, should always be stored with the concrete publication (book, article, ...)

Print-Series: In-reference: no need, leads to confusion

The notes added in comment 19 should go into a separate taxeditor ticket since this ticket here is mainly focused on the vaadin reference editor.

I think it is also worth mentioning the class eu.etaxonomy.cdm.model.reference.ReferencePropertyDefinitions which has been created to allow UIs to adapt to ReferenceType changes dynamically. The ReferenceType specific interfaces like IJournal, ... , are not very useful in this context and are actually not used at all except for the methods in the Reference class. Maybe we should consider to remove these interfaces.

Maybe we should also remove DOI from journal and print series.

Andreas Kohlbecker wrote:

The notes added in comment 19 should go into a separate taxeditor ticket since this ticket here is mainly focused on the vaadin reference editor.

The comments are not TaxEditor specific. They are general explaining CDM types. Implementation should be the same for Vaadin or TaxEditor. For specific issues seperate CDM tickets have be created.

Andreas Kohlbecker wrote:

I think it is also worth mentioning the class eu.etaxonomy.cdm.model.reference.ReferencePropertyDefinitions which has been created to allow UIs to adapt to ReferenceType changes dynamically. The ReferenceType specific interfaces like IJournal, ... , are not very useful in this context and are actually not used at all except for the methods in the Reference class. Maybe we should consider to remove these interfaces.

I don't like the fact that we have this information now at 2 different places. This makes changes like the one I implemented for the interfaces difficult to maintain. ReferencePropertyDefinitions uses hardcoded strings, why do we not use reflection on the interfaces? This way both systems can be easily maintained and are always up-to-date. At least tests are a strict requirement for hardcoded strings which immediately show the requirement to change the code if something changes elsewhere.

In future we may also use the new property path framework, once it is developed.

Interfaces are for both documentation (e.g. https://cybertaxonomy.eu/cdm/latest/index.htm?goto=10:283) and type save programming (e.g. programming an import by using the interfaces prevents the programmer from doing incorrect mappings). Therefore they should not be deleted.

Andreas Müller wrote:

Andreas Kohlbecker wrote:

The notes added in comment 19 should go into a separate taxeditor ticket since this ticket here is mainly focused on the vaadin reference editor.

The comments are not TaxEditor specific. They are general explaining CDM types. Implementation should be the same for Vaadin or TaxEditor. For specific issues seperate CDM tickets have be created.

The comments are not TaxEditor specific.

Ok, ok, agreed!!! But this Issue still is dedicated to the vaadin reference editor and it will be closed once the review regarding this editor has been completed.

Andreas Müller wrote:

Andreas Kohlbecker wrote:

I think it is also worth mentioning the class eu.etaxonomy.cdm.model.reference.ReferencePropertyDefinitions which has been created to allow UIs to adapt to ReferenceType changes dynamically. The ReferenceType specific interfaces like IJournal, ... , are not very useful in this context and are actually not used at all except for the methods in the Reference class. Maybe we should consider to remove these interfaces.

I don't like the fact that we have this information now at 2 different places. This makes changes like the one I implemented for the interfaces difficult to maintain. ReferencePropertyDefinitions uses hardcoded strings, why do we not use reflection on the interfaces? This way both systems can be easily maintained and are always up-to-date. At least tests are a strict requirement for hardcoded strings which immediately show the requirement to change the code if something changes elsewhere.

In future we may also use the new property path framework, once it is developed.

Interfaces are for both documentation (e.g. https://cybertaxonomy.eu/cdm/latest/index.htm?goto=10:283) and type save programming (e.g. programming an import by using the interfaces prevents the programmer from doing incorrect mappings). Therefore they should not be deleted.

Thank you for mentioning cdmlib-apps and the UML based documentation on the cdm model. I really thought that these reference interfaces are not used at all. Removing unused code would have reduced the efforts in maintaining code changes. From the broader view on the usage of these interfaces it is clear that we need to keem 'em.

The type level java doc of ReferencePropertyDefinitions already mentions the need to overcome the duplication if the information provided by the interfaces and by this class. Using pure reflection to obtain the needed information will not be sufficient, though. For example ISection declares the property inReference, IInProceedings which extends ISection declares the property inProceedings. From using pure reflection the Sections would have both, inReference and inProceedings even if inProceedings is just a "renaming" of the property inReference.

For dynamically adapting UIs to reference type changes more information is needed. The information that inProceedings is referring to the same field just with another "label" is required. So it is obvious that we need an additional source of information. Creating a method level annotation which is evaluated by ReferencePropertyDefinitions could be one solution to this problem.

=> #8255

InProceedings - Series: Correct, that this is not needed.
Also it is not available in the IInProceedings interface so I wonder how it made it's way into the TaxEditor. Please remove.

The inSeries comes from ISection which is extended by IInProceedings

I now moved the model discussion to #7918.

After discussion with Henning DOI should not be available for journals and print series.

And I guess also for personal communication no DOI should be available.

"And I guess also for personal communication no DOI should be available." correct.