[tdwg-content] [tdwg-tag] Inclusion of authorship in DwCscientificName: good or bad?

[Tony.Rees at csiro.au]

Hi David,

The problem is with the present DwC definition of scientificName- it is expected to contain authorship if the latter is available. (I presume Dima did the last upload into GNI so you could ask him what actually happens).

Cheers - Tony
 

> -----Original Message-----
> From: David Remsen (GBIF) [mailto:dremsen at gbif.org]
> Sent: Friday, 26 November 2010 7:39 PM
> To: Rees, Tony (CMAR, Hobart)
> Cc: David Remsen (GBIF); deepreef at bishopmuseum.org; m.doering at mac.com;
> Chuck.Miller at mobot.org; tdwg-content at lists.tdwg.org; dmozzherin at eol.org
> Subject: Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in
> DwCscientificName: good or bad?
> 
> Tony
> 
> Why isn't this something the GNI would address?  I don't see the
> problem with DwC.   What is scientificNameAuthor supposed to be used
> for if it isn't to store the authorship information from a scientific
> name?
> 
> If we really need to make strict distinctions and can't deal with just
> the two name parts,  then the logical new term needs to be
> scientificNameVerbatim or scientificNameWithAuthorship,  not canonical
> name.
> 
> David
> 
> On Nov 26, 2010, at 1:11 AM, <Tony.Rees at csiro.au> <Tony.Rees at csiro.au>
> wrote:
> 
> > Hi David, all,
> >
> > It is also important to follow the trail of how the name information
> > then gets passed on to other systems e.g. harvested into GNI etc. My
> > impression is that currently, if dwc:scientificName holds a sciname
> > without authorship and the latter information is put into
> > dwc:scientificNameAuthor, then the version that is harvested into
> > GNI (presuming that happens) loses the authority information, which
> > is definitely a bad thing...
> >
> > Cheers - Tony
> >
> >
> >> -----Original Message-----
> >> From: David Remsen (GBIF) [mailto:dremsen at gbif.org]
> >> Sent: Thursday, 25 November 2010 8:00 PM
> >> To: Richard Pyle
> >> Cc: David Remsen (GBIF); Rees, Tony (CMAR, Hobart);
> >> m.doering at mac.com;
> >> Chuck.Miller at mobot.org; tdwg-content at lists.tdwg.org; dmozzherin at eol.org
> >> Subject: Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in
> >> DwCscientificName: good or bad?
> >>
> >>> The thing that concerns me about 3a is the conditional definition of
> >>> scientificName (i.e., it excludes authorship when that information
> >>> is
> >>> pre-parsed, but includes it when it's not pre-parsed).
> >>
> >> right.  That is where we are today.  We need to test the contents
> >> every time.   One thing we are developing requirements for is a
> >> DarwinCore Archive "Normaliser" which would be a web service/web app
> >> client  that can accepted a DwC-A as input and would output the same
> >> data as a new DwC-A that conforms to a set of rules based on those
> >> requirements.  So one thing would be to parse the names into the
> >> authorship field for simpler consumption.
> >>
> >>> The thing that concerns me about 3b is that scientificName is
> >>> (supposedly?)
> >>> required; so if someone with unparsed information provides
> >>> scientificNameWithAuthorship, then are they supposed to leave
> >>> scientificName
> >>> blank?
> >>
> >> The short answer is yes,  they would leave it blank.  if they could
> >> parse it then they would have put the parts into name and author
> >> elements in the first place.   I also think the inverse is true.  If
> >> it is already split and they put it into name and author fields -
> >> they
> >> won't concatenate and put a new, merged copy into a name+authorship
> >> field.
> >>
> >> In regard to the requirement confusion - either we keep
> >> dwc:scientificName alone and have a simple requirement test or we add
> >> a new term and make it a conditional requirement.  My point was,  if
> >> we add a new term,  then the set (scientificNameWithAuthorship,
> >> scientificName, scientificNameAuthorship) is more clear than
> >> (canonicalName, scientificName, scientificNameAuthorship)
> >>
> >> DR
> >>
> >>
> >>>
> >>> Rich
> >>>
> >>>
> >>>
> >
> >