Issue 10150
Modify academic reference section?
10150
Reporter: omeyn
Type: SubTask
Summary: Modify academic reference section?
Priority: Major
Resolution: Fixed
Status: Closed
Created: 2011-11-07 16:52:30.401
Updated: 2013-08-29 14:46:11.787
Resolved: 2011-11-16 10:30:09.943
Author: omeyn@gbif.org
Created: 2011-11-07 16:53:27.8
Updated: 2011-11-07 16:53:27.8
Markus Döring Tue, 27 Sep at 6:09am
Dont think we got this in clb nor darwin core
Kyle Braak Tue, 27 Sep at 8:57am
In the literature references extension ( http://rs.gbif.org/extension/gbif/1.0/references.xml ) there is date described as:
Date of publication, recommended ISO format YYYY or YYYY-MM-DD
Perhaps Publication Date makes a more suitable name than Review Date?
Andrea Hahn Wed, 28 Sep at 3:53am
To be honest, I am not quite sure where we would get "According to" information from, either. The publication date should typically be already part of the bibliographical reference (current header: Publication), so it would not be necessary to repeat. I agree the review date does no make sense. On the other hand, the reference example is incomplete (title missing).
Suggestion:
- under "Publication", give the full reference according to bibliographicCitation at http://rs.gbif.org/extension/gbif/1.0/references.xml
- evaluate the "type" to chose the most appropriate publication(s) for the main left section of the block (original > combination > monograph, see http://rs.gbif.org/vocabulary/gbif/reference_type.xml)
- add the identifier (http://rs.gbif.org/extension/gbif/1.0/references.xml) where available
Markus Döring Wed, 28 Sep at 10:12am
see excel sheet, but publishedIn and accordingTo comes from the core NameUsage and not the publication extension. That is only populating the right hand side (which might be weird as this list can grow large, while the 3 on the left are fixed single terms
Markus Döring Wed, 28 Sep at 10:14am
but still I have no idea what reviewDate is.
I woud even suggest to consider moving publishedIn and accordingTo to the top overview block as its an important piece of information, we got many of that and its restricted to 2 simple values we can nicely integrate
Kyle Braak Thu, 29 Sep at 2:31am
If the top overview block had publishedIn and accordingTo, would they then only be populated from the reference always having the type original? Or would we populate it from the best available one in terms of our priority for the type (original > combination > monograph)?
Andrea Hahn Thu, 29 Sep at 2:44am
I thought I had already written, but apparently forgot: I don't know what the review date is, either, same with "according to", and suggest to scratch both and use the format sketched above for the time being. If we move any bibliographical things up into the overview block at all, I would propose to only do that if we have the original description, clearly marked as such, but not anything else. Any other publication should stay in the references block at the bottom,
Markus Döring Thu, 29 Sep at 3:35am
Seems we have caused a great confusion. It really is rather simple where the data comes from apart from the reviewDate which none seems to have an idea what it is. Let me summarize:
the core name usage has a term dwc:accordingTo which is a string and specifies the usage of that name according to someone. It is the sec/sensu reference of a (potential) taxon concept. For example in Abies alba Mill. sec. Berendsohn Berendsohn would be the accordingTo. In catalogue of life it is used to reference the person who did the latest review of the species (they call it latest scrutiny). Those cases are all for name usages only - in the nub we currently keep the source checklist name that was used as the primary "template" for the nub record. Im not sure if this is the best way to show that actually. I would prefer to have a proper link to the primary source usage (this can be taken from the species Identifiers with type=SourceID) and show the accordingTo only on name usage pages.
dwc:publishedIn is also a simple String found in the core Taxon class. It is the full, unparsed reference to the original publication of that name. Often in particular for botanical names, we get an abbreviated reference. For example Gard. dict. ed. 8: Abies no. 1. 1768 for Abies alba in the ecat portal: http://ecat-dev.gbif.org/usage/2685484 ;
All other references come from the bibliography extension. Each reference can be given as a single string AND as a parsed version. As we can't rely on the parsed version I would suggest to ignore that and only show the full string which we can easily assemble from records with parsed only data. In addition the references SHOULD have a type categorizing them. But that is not required at all. Nevertheless we should use it to group the reference list if we have it at hand.
To me the only open questions are:
where do we show accordingTo and publishedIn?
how do we best show the bibliography which can grow quite large in some cases
should we remove the reviewDate? I guess the idea is to have a date that tells when this species was last revised, but I have no idea where this information should come from. Unless we show the date the nub was build the last time - which should be shown at least on the dataset view.
Markus Döring Tue, 18 Oct at 4:00pm
I made the reference section live in the staging portal. Here is a typical example of a usage with some references (close to bottom):
http://staging.gbif.org:8080/portal-web-dynamic/species/103342522/name_usage
Shouldn't we move the bibliography to the left?
And consider moving the publishedIn & accordingTo (which is a common property across all checklists) to the overview?
Kyle Braak Wed, 19 Oct at 2:22am
The section looks rather strange with a lengthy right sidebar and mostly empty content. +1 for your suggestion.
Andrea Hahn Wed, 19 Oct at 2:41am
Agree. Please maintain the top section (citation of original description) in its current position for the time being, though, and move the bibliography underneath.
Andrea Hahn Wed, 19 Oct at 2:54am
In general: please keep in mind that in the right hand section (also in other places / boxes), a "more..." link to open a separate window is to be used in all cases where the section otherwise gets disproportionately longer than the left part. This is not included in the design sketch in all places, but is the general guideline.
Markus Döring Wed, 19 Oct at 2:57am
Ok. Done. Could be ok like this, just the right hand side is now always empty.
Does that matter? Can we use the full width?
Andrea Hahn Wed, 19 Oct at 3:01am
Let's not break the general design guidelines at this stage yet.
Markus Döring Wed, 19 Oct at 3:05am
Yes. It would be good if visuality would review every single page once we have them all wired up. There is lots of unbalanced layout now with real data. But that was expected.