Issue 10451

Scientific names should be italicized?

Reporter: trobertson
Type: Improvement
Summary: Scientific names should be italicized?
Priority: Minor
Resolution: WontFix
Status: Closed
Created: 2011-11-23 14:14:22.595
Updated: 2017-06-12 10:53:59.412
Resolved: 2016-09-05 13:34:39.798
Description: Should scientific names be italicized as we do in

Comment: Yes - this is the first detail scientists always stumble over when looking at demo pages, so it will be turning up as a bug report pretty soon anyway. Make sure syntactic elements ("var.", "subsp.") are _not_ italicized, though
Created: 2011-11-23 16:30:05.988
Updated: 2011-11-23 16:30:05.988

Created: 2011-11-28 10:45:19.765
Updated: 2011-11-28 10:45:19.765
If this is a real requirement we need some serious change from a single string to a ParsedName instance, affecting all our software layers starting from the model classes. Might be a good thing to do this now anyway, as there will probably be more requirements that require access to the parsed name.

So, are italicized names required - at least at some point?

Created: 2011-11-28 11:08:35.578
Updated: 2011-11-28 11:08:35.578
I would think this is necessary and looking at ALA, I would expect Donald to want this as well (he did in the GBIF Portal):

Regarding implementation, could we leave software layers alone, and write a tag that uses the parser to atomize for display purposes?  Or have the tag do a callback to get the atomized name?  (nameService.getAtomized(String canonical) or nameService.getAtomized(String usageKey)) ?  I am pretty sure this is how we did it in the portal implementation.

We make almost exclusive use of the ability to atomize names confidently using the name parser during things like rollover.  I can't say if the same is true for CLB, which might make more use of atoms during importing.


Created: 2011-11-29 21:27:59.056
Updated: 2011-11-29 21:27:59.056
If we entirely rely on the parser there will always be non or wrongly parsed names left no matter how often we improve it. CLB was designed to store the parsed names and allow manual or other software intervention if needed. Reparsing the name string every time does not feel like a reliable thing to do. Although a custom tag that does this is a nice thing to have for sure. Pretty sweet actually.

Still, Im a bit uncomfortable with this approach and would prefer to use the persisted parsed name. If we retrieve it eagerly as part of a name usage or as a separate call through the action I don't mind too much. Having tags that issue web service calls seems dangerous to performance and hiding logic - Id rather keep all that within the action/controller. Thinking about it we probably need to retrieve the parsed name for every name usage on pretty much any page - so eagerly loading it seems the right thing to do to me.