EDIT

[copied from #7223#note-19 , Andreas Müller]

Some notes on the above:

DOIs: are available but just not implemented yet => #3767 (implemented in v5.5)

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 => copied to #7987 and #7988

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 => copied to #7983

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). => copied to #7984

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. => copied to #7985

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

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

[partially copied from #7223#note-12 , Andreas Kohlbecker]

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.

[copied from #7223#note-26 , Andreas Müller]

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.

[copied from #7223#note-28 , Andreas Kohlbecker]

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

[copied from #7223#note-29 , Andreas Kohlbecker]

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

Andreas Kohlbecker wrote:

[copied from #7223#note-29 , Andreas Kohlbecker]

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 can't see inSeries in ISection !!

Andreas Müller wrote:

Andreas Kohlbecker wrote:

[copied from #7223#note-29 , Andreas Kohlbecker]

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 can't see inSeries in ISection !!

I am absolutely astonished, I swear I've seen it. The question is: Where? Maybe I was confused by the same thing that lead Katja to the assumption that inSeries is relevant for IInProceedings.

Andreas Kohlbecker wrote:

this should be complete now except of the fact that ISection inherits datePublished from IWithAuthorAndDate, which makes no sense in my eyes.

I can't see why this should not make sense. Most often ISection may inherit datePublished from it's parent, however, there are cases were parts of references have a different publication date than other parts of publications. And as ISection is a somehow generic case for handling in-references it should allow explicit date published.
But maybe this is not what you meant by "makes no sense"?

for Reference type = PrintSeries see task #8091