- tdwg-content - lists.tdwg.org

Re: [tdwg-content] [tdwg-tag] Canonical name parsing
by Paul van Rijckevorsel 15 Mar '12

15 Mar '12

----- Original Message ----- From: "Paul Kirk" <p.kirk(a)cabi.org> Sent: Wednesday, March 14, 2012 7:34 PM and ... an infraspecific name in ICNAFP (previously ICBN) without an infraspecific rank-indicator is NOT a name, so less than useless ... :-) *** Surely this is not right. The "connecting term" denoting the rank is not part of the name. However, its use is mandatory. In higher ranks a similar problem may occur, where a non-standard termination is used or where a name may be used in more than one rank. Anyway, it never hurts to have a rank-indicating term for names in higher ranks, for those users who are not familiar with the standard terminations. Paul P.S. I would guess "ICNafp"?

1 0

Re: [tdwg-content] [tdwg-tag] Canonical name parsing
by Peter Desmet 14 Mar '12

14 Mar '12

Hi Paul, Higher taxon: "Magnoliidae Novák ex Takhtajan" (a subclass). - scientificName: Magnoliidae Novák ex Takhtajan - taxonRank: subclass But there are no terms to share the canonical name "Magnoliidae". The only available options are kingdom, phylum, class, order, family, genus, subgenus, specificEpithet, infraspecificEpithet, none of which are appropriate. Solution: - canonicalScientificName: Magnoliidae Infrageneric taxon: "Abies sect. Amabilis (Matzenko) Farjon & Rushforth" (a section) - scientificName: Abies sect. Amabilis (Matzenko) Farjon & Rushforth - taxonRank: section - genus: Abies But there are no terms to share "Abies Amabilis", "Abies sect. Amabilis", "Abies section Amabilis" or even "Amabilis". The only available options are kingdom, phylum, class, order, family, genus, subgenus, specificEpithet, infraspecificEpithet, none of which are appropriate. Why we have subgenus, but not *infragenericEpithet* is another issue. I would at least be able to share "Amabilis". Solution: - canonicalScientificName: Abies Amabilis - taxonRank: section Peter There is no place to share the canonical name "Magnoliidae" for this taxon. On Wed, Mar 14, 2012 at 14:37, Paul Kirk <p.kirk(a)cabi.org> wrote: > 'For higher taxa or infrageneric taxa, these terms are not sufficient' > ... why? > > > > Paul > > > > ------------------------------ > > *From:* tdwg-tag-bounces(a)lists.tdwg.org [tdwg-tag-bounces(a)lists.tdwg.org] > on behalf of Peter Desmet [peter.desmet(a)umontreal.ca] > *Sent:* 14 March 2012 18:26 > *To:* Richard Pyle > *Cc:* TDWG content mailing list; Donald Hobern (GBIF); dev Developers; > Christian Gendreau; TDWG TAG mailing list > > *Subject:* Re: [tdwg-tag] [tdwg-content] Canonical name parsing > > Rich, > > I wished those terms were sufficient, but as mentioned in the > justification for http://code.google.com/p/darwincore/issues/detail?id=150 > : > > genus, specificEpithet, infraspecificEpithet: concatenated, this terms are identical to the canonicalScientificName for genera, species and infraspecific taxa. For higher taxa or infrageneric taxa, these terms are not sufficient. In addition, there is some ambiguity regarding the genus definition: for synonyms, is it the accepted genus or the genus that is part of the synonym name? See: http://lists.tdwg.org/pipermail/tdwg-content/2010-November/002052.html. In the former case, the genus cannot be used to concatenate a canonicalScientificName. > > To give an example for a higher taxon: > scientificName: Magnoliidae Novák ex Takhtajan > taxonRank: subclass > > There is no place to share the canonical name "Magnoliidae" for this > taxon. > > Peter > > On Wed, Mar 14, 2012 at 14:13, Richard Pyle <deepreef(a)bishopmuseum.org>wrote: > >> >> I guess the parts that confuse me are: >> >> 1) What providers are able to produce a canonicalScientificName as per >> Peter’s definition, but are unable to provide the pre-parsed elements of >> genus | subgenus | specificEpithet | infraspecificEpithet? >> >> 2) What consumers could make use of a canonicalScientificName as per >> Peter’s definition, but are unable to make (even better) use of the >> pre-parsed elements of genus | subgenus | specificEpithet | >> infraspecificEpithet? >> >> Aloha, >> Rich >> >> >> >> >> From: tdwg-content-bounces(a)lists.tdwg.org [mailto: >> tdwg-content-bounces(a)lists.tdwg.org] On Behalf Of Peter Desmet >> Sent: Wednesday, March 14, 2012 7:03 AM >> To: Donald Hobern (GBIF) >> Cc: TDWG content mailing list; Christian Gendreau; Tim Robertson [GBIF]; >> TDWG TAG mailing list; dev Developers >> Subject: Re: [tdwg-content] Canonical name parsing >> >> Hi Donald, >> >> scientificName, with its current definition [1] is a great term and >> should be continued to used as such. As with most Darwin Core terms, it >> offers flexibility, so its not an impediment for publishing data. In the >> GBIF context, this term is considered mandatory: records without it are >> ignored during indexing (I believe). All of this can stay. >> >> canonicalScientificName would be an additional term with a clear rule >> (see my proposed definition [2]). This is the case for other Darwin Core >> terms as well, such as >> decimalLatitude [3], minimalElevationInMeters [4] or countryCode [5]. >> They serve as an ready-to-use addition/alternative to verbatimLatitude [6], >> verbatimElevation [7] and country [8] respectively. These terms don't stop >> anyone from publishing data, but data publishers who can provide this kind >> of information have the choice to do so. It would be the same for >> canonicalScientificName. >> >> And yes, an aggregator like GBIF can play an important role in providing >> consistent data to its users and figuring out what they really need, but >> not all data is consumed that way. In addition, I hope a user would be able >> to download cleaned data from the GBIF portal as Darwin Core. Wouldn't it >> be nice that the parsed canonicalScientificName created by GBIF can be >> provided in its proper term? There are users out there who want this! >> >> Regards, >> >> Peter >> >> [1] http://rs.tdwg.org/dwc/terms/index.htm#scientificName >> [2] http://code.google.com/p/darwincore/issues/detail?id=150 >> [3] http://rs.tdwg.org/dwc/terms/index.htm#decimalLatitude >> [4] http://rs.tdwg.org/dwc/terms/index.htm#minimumElevationInMeters >> [5] http://rs.tdwg.org/dwc/terms/index.htm#countryCode >> [6] http://rs.tdwg.org/dwc/terms/index.htm#verbatimLatitude >> [7] http://rs.tdwg.org/dwc/terms/index.htm#verbatimElevation >> [8] http://rs.tdwg.org/dwc/terms/index.htm#country >> >> On Wed, Mar 14, 2012 at 11:19, Donald Hobern (GBIF) <dhobern(a)gbif.org> >> wrote: >> > >> > Hi Peter. >> > >> > I certainly agree that aggregators only represent one use case here >> but, having seen a lot of the mess of real-world data, I don't believe that >> simply adding a new term will fix this problem for the users you describe. >> To get the results you want, we would need a sufficiently large majority >> of data sets to follow the rules perfectly that we could ignore those that >> were non-conformant. This would mean we should mandate that every data set >> must use the new element (with or without the existing scientificName >> element) and that they must present scientific names in the expected way >> (or else have their data considered non-compliant). Until now, the >> philosophy on publishing Darwin Core data has been to make it as easy as >> possible for data providers to expose their data, even at the expense of >> greater complexity for consumers. I suspect that we would have a lot less >> data available for use now if we had taken a more stringent approach. >> > >> > In some ways, this proposal reminds me of the structures in ABCD which >> seek to offer users verbatim and more normalised ways to represent several >> types of information. This actually makes consuming all the possible forms >> of such data very complex, since a record may contain all variant forms or >> just any one of them. If multiple forms are available, which one should be >> considered the primary version? >> > >> > I suspect that things may also get complicated as soon as you discuss >> botanical subspecies, varieties, subvarieties, forms and subforms. There >> are recommended ways to abbreviate the rank markers in these cases but some >> variation can be expected. >> > >> > Of course aggregators should be providing more robust services for >> accessing exactly what you want in a consistent, predictable way and I >> would suggest that the best place to attack the problem is to define >> exactly what a typical user needs to see and then for GBIF and similar >> projects to work on delivering predictable data downloads and web services >> that clean out all of these nomenclatural inconsistencies - and perhaps >> also add value in other ways such as augmenting the data with associated >> environmental values (as the Atlas of Living Australia does). This would >> allow us all to work together on developing a consistent and predictable >> algorithm for handling interpretation of name strings, including synonymy, >> misspellings, virus names and everything else that makes this such a >> difficult problem. >> > >> > Best wishes, >> > >> > Donald >> > >> > ---------------------------------------------------------------------- >> > Donald Hobern - GBIF Director - dhobern(a)gbif.org >> > Global Biodiversity Information Facility http://www.gbif.org/ >> > GBIF Secretariat, Universitetsparken 15, DK-2100 Copenhagen Ø, Denmark >> > Tel: +45 3532 1471 Mob: +45 2875 1471 Fax: +45 2875 1480 >> > ---------------------------------------------------------------------- >> > >> > >> > -----Original Message----- >> > From: peter.desmet.cubc(a)gmail.com [mailto:peter.desmet.cubc@gmail.com] >> On Behalf Of Peter Desmet >> > Sent: Wednesday, March 14, 2012 3:41 PM >> > To: Tim Robertson [GBIF] >> > Cc: Donald Hobern (GBIF); dev Developers; TDWG content mailing list; >> TDWG TAG mailing list; Christian Gendreau >> > Subject: Re: Canonical name parsing >> > >> > Hi Tim, >> > >> > I agree, aggregators like GBIF and Canadensys will have to deal with >> clean and dirty data in each field anyway: they need code libraries to deal >> with this and it is good that these are being developed. But, that doesn't >> help someone who wants to use data from a Darwin Core Archive with his data >> in Excel or a Roderic Page who wants to get things done for a prototype. >> > Having to use Java libraries or even the Name Parser [1] (though both >> > great) is a barrier to data use. Darwin Core (Archives) is not only >> used for machine to machine interaction, humans use it too, and I think we >> should allow easy hacking (I mean this in the good sense), especially for >> something as important as the scientific name. >> > In addition, as a data publisher (e.g. for our VASCAN checklist) I >> > *do* have the information to provide a clean and simple to use >> canonicalScientificName, but I just can't share it via the otherwise >> excellent biodiversity sharing standard Darwin Core. I think that's a pity. >> > >> > Peter >> > >> > [1] http://tools.gbif.org/nameparser/ >> > [2] http://data.canadensys.net/vascan >> > >> > PS: Yes, Canadensys will use the GBIF interpretation libraries. Since >> we develop in Java as well, using those libraries is as easy as the >> proverbial "one line of code". We're looking forward in testing them and >> providing patches to enhance them. Open source FTW! :-) >> > >> > >> > On Wed, Mar 14, 2012 at 07:32, Tim Robertson [GBIF] < >> trobertson(a)gbif.org> wrote: >> > > Hi Peter, >> > > >> > > I'm replying off the TDWG list, since it is a bit of a tangent to >> your discussion. If you feel it is relevant, please CC the list again. >> > > >> > > At GBIF as you know, we have to interpret all kinds of quality of >> content. I tend to agree with Donald that this would not really help in >> consumption, as in my experience we will have to deal with both clean and >> dirty data in each field *anyway* when this is used at network scale. I >> would rather see us evolve the interpretation libraries to handle all the >> corner cases, which we need to develop anyway. We already do a pretty >> decent job at extracting canonicals. This is further enhanced when you >> couple the extracted canonical with a fuzzy match against the >> "authoritative names" we can now index thanks to the availability of >> checklists in DwC-A format. >> > > >> > > I know you are a Java shop. Are you using the GBIF interpretation >> libraries [1] at the moment? If not, is there a reason why you don't? >> > > They are used in all GBIF projects (portal, checklistbank etc), and >> the more we enhance them, the better it is for everyone. We have a >> significant test coverage [2,3] and there have been quite some man months >> (years?) spent already in their development and with some real regular >> expression experts (most notably Markus D. and Dave M.). All our work is >> Maven-ized, versioned and available in our Maven repository [4]. >> > > >> > > I hope these are interesting to you. We would welcome any patches to >> enhance them, or assistance in identifying the corner cases and capturing >> those as unit tests. >> > > >> > > Hope this helps, >> > > Tim >> > > >> > > [1] >> > > >> http://code.google.com/p/gbif-ecat/source/browse/trunk/ecat-common/src >> > > /main/java/org/gbif/ecat/parser/NameParser.java >> > > [2] >> > > >> http://code.google.com/p/gbif-ecat/source/browse/trunk/ecat-common/src >> > > /test/java/org/gbif/ecat/parser/NameParserTest.java >> > > [3] >> > > >> http://code.google.com/p/gbif-ecat/source/browse/trunk/ecat-common/src >> > > /#src%2Ftest%2Fresources [4] >> > > http://repository.gbif.org/index.html#nexus-search;quick~ecat-common >> > > >> > >> > >> > >> > -- >> > Peter Desmet >> > Biodiversity Informatics Manager >> > Canadensys - www.canadensys.net >> > >> > Université de Montréal Biodiversity Centre >> > 4101 rue Sherbrooke est >> > Montreal, QC, H1X2B2 >> > Canada >> > >> > Phone: 514-343-6111 #82354 >> > Fax: 514-343-2288 >> > Email: peter.desmet(a)umontreal.ca / peter.desmet.cubc(a)gmail.com >> > Skype: anderhalv >> > Public profile: http://www.linkedin.com/in/peterdesmet >> > >> > >> > _______________________________________________ >> > tdwg-content mailing list >> > tdwg-content(a)lists.tdwg.org >> > http://lists.tdwg.org/mailman/listinfo/tdwg-content >> >> >> >> >> -- >> Peter Desmet >> Biodiversity Informatics Manager >> Canadensys - www.canadensys.net >> >> Université de Montréal Biodiversity Centre >> 4101 rue Sherbrooke est >> Montreal, QC, H1X2B2 >> Canada >> >> Phone: 514-343-6111 #82354 >> Fax: 514-343-2288 >> Email: peter.desmet(a)umontreal.ca / peter.desmet.cubc(a)gmail.com >> Skype: anderhalv >> Public profile: http://www.linkedin.com/in/peterdesmet >> >> >> This message is only intended for the addressee named above. Its >> contents may be privileged or otherwise protected. Any unauthorized use, >> disclosure or copying of this message or its contents is prohibited. If >> you have received this message by mistake, please notify us immediately by >> reply mail or by collect telephone call. Any personal opinions expressed >> in this message do not necessarily represent the views of the Bishop Museum. >> _______________________________________________ >> tdwg-content mailing list >> tdwg-content(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-content >> > > > > -- > Peter Desmet > Biodiversity Informatics Manager > Canadensys - www.canadensys.net > > Université de Montréal Biodiversity Centre > 4101 rue Sherbrooke est > Montreal, QC, H1X2B2 > Canada > > Phone: 514-343-6111 #82354 > Fax: 514-343-2288 > Email: peter.desmet(a)umontreal.ca / peter.desmet.cubc(a)gmail.com > Skype: anderhalv > Public profile: http://www.linkedin.com/in/peterdesmet > > P Think Green - don't print this email unless you really need to** ** > > ************************************************************************ > The information contained in this e-mail and any files transmitted with it > is confidential and is for the exclusive use of the intended recipient. If > you are not the intended recipient please note that any distribution, > copying or use of this communication or the information in it is > prohibited. > > Whilst CAB International trading as CABI takes steps to prevent the > transmission of viruses via e-mail, we cannot guarantee that any e-mail or > attachment is free from computer viruses and you are strongly advised to > undertake your own anti-virus precautions. > > If you have received this communication in error, please notify us by > e-mail at cabi(a)cabi.org or by telephone on +44 (0)1491 832111 and then > delete the e-mail and any copies of it. > > CABI is an International Organization recognised by the UK Government > under Statutory Instrument 1982 No. 1071... > > ************************************************************************** > **** > > > _______________________________________________ > tdwg-tag mailing list > tdwg-tag(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag > > -- Peter Desmet Biodiversity Informatics Manager Canadensys - www.canadensys.net Université de Montréal Biodiversity Centre 4101 rue Sherbrooke est Montreal, QC, H1X2B2 Canada Phone: 514-343-6111 #82354 Fax: 514-343-2288 Email: peter.desmet(a)umontreal.ca / peter.desmet.cubc(a)gmail.com Skype: anderhalv Public profile: http://www.linkedin.com/in/peterdesmet

4 4

canonicalScientificName
by Peter Desmet 14 Mar '12

14 Mar '12

Hi everyone, In a recent tweet [1] Roderic Page reminded me that in Darwin Core, we don't have a ready-to-use scientificName field. The definition for scientificName [2] asks for the full verbose name, including authors. I think this is a good definition (see below), but it also means that in a lot of use cases, names need to be parsed before they can be used or matched. I am currently helping collections publish their data for Candensys [3] and as a data producer I am happy we can provide all the information we have in scientificName, but as a data user, I get frustrated every time I see those long verbose botanical names with multiple authors. I am convinced that our data would be more usable if we had an additional canonicalScientificName term. Which is why I am now officially requesting it on the Darwin Core code site: http://code.google.com/p/darwincore/issues/detail?id=150 (see below). This has been discussed in detail before [4], but no consensus was reached. I hope we can get our act together this time! Regards, Peter Desmet -- [1] https://twitter.com/#!/rustyrussell22/status/179500954901692417 [2] http://rs.tdwg.org/dwc/terms/index.htm#scientificName [3] http://www.canadensys.net [4] http://lists.tdwg.org/pipermail/tdwg-content/2010-November/thread.html#1976 ==New Term Recommendation== Submitter: Peter Desmet Justification: The scientific name is probably the most used element of an occurrence/taxon, but currently Darwin Core does not provide a single ready-to-use-field for this. A canonicalScientificName with the scientific name as a uninomial, binomial or trinomial could solve this problem. The current terms are not sufficient: - scientificName: verbose, used to record all components of a scientific name (if available), including authorship(s) and rankmarker(s). It is critical to keep this definition, as this term is sometimes the only place to share certain information, e.g.: quadrinomials, intermediate botanical authors, hybrid formulas, etc. The disadvantage of only having this verbose notation is that the user needs to parse the name before he/she can use or match it. - genus, specificEpithet, infraspecificEpithet: concatenated, this terms are identical to the canonicalScientificName for genera, species and infraspecific taxa. For higher taxa or infrageneric taxa, these terms are not sufficient. In addition, there is some ambiguity regarding the genus definition: for synonyms, is it the accepted genus or the genus that is part of the synonym name? See: http://lists.tdwg.org/pipermail/tdwg-content/2010-November/002052.html. In the former case, the genus cannot be used to concatenate a canonicalScientificName. The need for this term has been discussed thoroughly already (see: http://lists.tdwg.org/pipermail/tdwg-content/2010-November/thread.html#1976), but no consensus was reached. I'd like to reopen the discussion and I hope that a consensus can be reached quickly, so our data can be used more easily. Definition: The scientific name as a uninomial, binomial or trinomial. When forming part of an Identification, this should be the name in lowest level taxonomic rank that can be determined. This term should not contain authorship(s), rankmarker(s) or identification qualifications. If the scientific name cannot be expressed as a uni-, bi- or trinomial (e.g. hybrid formulas), do not use this term (use scientificName instead). Comment: Examples: "Carex" (genus), "Vulpes vulpes" (species), "Anaphalis margaritacea occidentalis" (plant variety) Refines: Has Domain: Has Range: Replaces: ABCD 2.06: -- Peter Desmet Biodiversity Informatics Manager Canadensys - www.canadensys.net Université de Montréal Biodiversity Centre 4101 rue Sherbrooke est Montreal, QC, H1X2B2 Canada Phone: 514-343-6111 #82354 Fax: 514-343-2288 Email: peter.desmet(a)umontreal.ca / peter.desmet.cubc(a)gmail.com Skype: anderhalv Public profile: http://www.linkedin.com/in/peterdesmet

6 9

Re: [tdwg-content] Canonical name parsing
by Peter Desmet 14 Mar '12

14 Mar '12

Hi Tim, I agree, aggregators like GBIF and Canadensys will have to deal with clean and dirty data in each field anyway: they need code libraries to deal with this and it is good that these are being developed. But, that doesn't help someone who wants to use data from a Darwin Core Archive with his data in Excel or a Roderic Page who wants to get things done for a prototype. Having to use Java libraries or even the Name Parser [1] (though both great) is a barrier to data use. Darwin Core (Archives) is not only used for machine to machine interaction, humans use it too, and I think we should allow easy hacking (I mean this in the good sense), especially for something as important as the scientific name. In addition, as a data publisher (e.g. for our VASCAN checklist) I *do* have the information to provide a clean and simple to use canonicalScientificName, but I just can't share it via the otherwise excellent biodiversity sharing standard Darwin Core. I think that's a pity. Peter [1] http://tools.gbif.org/nameparser/ [2] http://data.canadensys.net/vascan PS: Yes, Canadensys will use the GBIF interpretation libraries. Since we develop in Java as well, using those libraries is as easy as the proverbial "one line of code". We're looking forward in testing them and providing patches to enhance them. Open source FTW! :-) On Wed, Mar 14, 2012 at 07:32, Tim Robertson [GBIF] <trobertson(a)gbif.org> wrote: > Hi Peter, > > I'm replying off the TDWG list, since it is a bit of a tangent to your discussion. If you feel it is relevant, please CC the list again. > > At GBIF as you know, we have to interpret all kinds of quality of content. I tend to agree with Donald that this would not really help in consumption, as in my experience we will have to deal with both clean and dirty data in each field *anyway* when this is used at network scale. I would rather see us evolve the interpretation libraries to handle all the corner cases, which we need to develop anyway. We already do a pretty decent job at extracting canonicals. This is further enhanced when you couple the extracted canonical with a fuzzy match against the "authoritative names" we can now index thanks to the availability of checklists in DwC-A format. > > I know you are a Java shop. Are you using the GBIF interpretation libraries [1] at the moment? If not, is there a reason why you don't? > They are used in all GBIF projects (portal, checklistbank etc), and the more we enhance them, the better it is for everyone. We have a significant test coverage [2,3] and there have been quite some man months (years?) spent already in their development and with some real regular expression experts (most notably Markus D. and Dave M.). All our work is Maven-ized, versioned and available in our Maven repository [4]. > > I hope these are interesting to you. We would welcome any patches to enhance them, or assistance in identifying the corner cases and capturing those as unit tests. > > Hope this helps, > Tim > > [1] http://code.google.com/p/gbif-ecat/source/browse/trunk/ecat-common/src/main… > [2] http://code.google.com/p/gbif-ecat/source/browse/trunk/ecat-common/src/test… > [3] http://code.google.com/p/gbif-ecat/source/browse/trunk/ecat-common/src/#src… > [4] http://repository.gbif.org/index.html#nexus-search;quick~ecat-common > -- Peter Desmet Biodiversity Informatics Manager Canadensys - www.canadensys.net Université de Montréal Biodiversity Centre 4101 rue Sherbrooke est Montreal, QC, H1X2B2 Canada Phone: 514-343-6111 #82354 Fax: 514-343-2288 Email: peter.desmet(a)umontreal.ca / peter.desmet.cubc(a)gmail.com Skype: anderhalv Public profile: http://www.linkedin.com/in/peterdesmet

5 8

Re: [tdwg-content] canonicalScientificName
by Donald Hobern 14 Mar '12

14 Mar '12

Hi Peter. I certainly sympathise with the desire for a readily-consumed naked scientific name field. However, unless the canonicalScientificName element is enforced as a mandatory field (which would in itself impact some data publishers and may prevent them validly sharing their data without extra work to provide clean scientific names), it will be yet another element which data consumers must check. If canonicalScientificName is supplied, consumers will still need to handle cases where it is malformed. If is not supplied, they will need to ignore the record or else do precisely what they do today with the scientificName field. I therefore worry that adding this field could in fact make the task more complex, rather than simpler, for data consumers. Thanks, Donald ---------------------------------------------------------------------- Donald Hobern - GBIF Director - dhobern(a)gbif.org Global Biodiversity Information Facility http://www.gbif.org/ GBIF Secretariat, Universitetsparken 15, DK-2100 Copenhagen Ø, Denmark Tel: +45 3532 1471 Mob: +45 2875 1471 Fax: +45 2875 1480 ----------------------------------------------------------------------

5 5

Applications open for iEvoBio 2012 Travel Awards
by Nico Cellinese 13 Mar '12

13 Mar '12

The 2012 conference on Informatics for Phylogenetics, Evolution, and Biodiversity (iEvoBio) is offering limited funds for travel expenses for the 2012 iEvoBio meeting in Ottawa, Canada. Preference will be given to participants lacking sources of funding for meeting attendance, such as graduate students, emerging professionals, and participants from underrepresented groups and countries. Please explain in an attached document the need for funding, the benefit that attending iEvoBio will afford you and how you will contribute to the meeting (max 350 words). We are looking for do-ers! A brief letter of support from your advisor, supervisor, or professional mentor should be submitted to the organizing committee (electronically), together with the application headed by the information below, to travelaward(a)ievobio.org by the deadline of 15 April 2012. Participants are required to make all their own travel arrangements, including visas and lodging, if required. Application format: Name: Contact information (address/phone/email): Academic Institution: Role (student, researcher, etc.): Origination of travel (if different from home institution) and estimated travel expenses: Explain the benefit that attending iEvoBio will afford you and what you will bring to the meeting (350 words or less):

1 0

Call for Abstracts open for Conference on Informatics for Phylogenetics, Evolution, and Biodiversity (iEvoBio)
by Nico Cellinese 03 Mar '12

03 Mar '12

The Call for Abstracts for full talks is now open for the 2012 conference on Informatics for Phylogenetics, Evolution, and Biodiversity (iEvoBio), at http://ievobio.org/ocs2/index.php/ievobio/2012. See below for instructions. Accepted talks will be 15 minutes in length and will be presented during the full talk session of the conference. Because the number of program slots for full talks is limited, some talks may be moved to the Lightning Talk session (5 minutes in length). Submitted talks should be in the area of informatics aimed at advancing research in phylogenetics, evolution, and biodiversity, including new tools, cyberinfrastructure development, large-scale data analysis, and visualization. Submissions should be 1 page long at most and include a title, a list of contributors, and an abstract. The abstract should provide an overview of the talk's subject, and give enough detail to allow reviewers to decide whether the submission merits a full talk, or whether it should be moved to a Lightning Talk session. If the subject of the talk is a specific software component for use by the research community, the abstract must state the license and give the URL where the source code is available so reviewers can verify that the open-source requirement(*) is met. The deadline for submission is April 2, 2012. We intend to notify authors of accepted talks before early registration for iEvoBio (and Evolution) ends. Further instructions for submission are at the following URL: http://ievobio.org/ocs2/index.php/ievobio/2012/schedConf/cfp Full talks are one of the five kinds of contributed content that feature in iEvoBio. The other four are: 1) Lightning talks (5 mins long), 2) Challenge entries, 3) Software bazaar demonstrations, and 4) Birds-of-a-Feather gatherings. The Call for Challenge entries is already open (see http://ievobio.org/challenge.html). The calls for contribution to the other three sessions will open later, and will remain open until shortly before the conference or until the respective track fills up. In addition, 2012 iEvoBio sponsor Biomatters Ltd will be running the Geneious Challenge alongside this year’s iEvoBio Challenge, see http://ievobio.org/geneious_challenge.html for more information. More details about the conference and program are available at http://ievobio.org. You can also find continuous updates on the conference's Twitter feed at http://twitter.com/iEvoBio and Google+ page, or subscribe to the low-traffic iEvoBio announcements mailing list at http://groups.google.com/group/ievobio-announce. iEvoBio 2012 is sponsored by the US National Evolutionary Synthesis Center (NESCent) and by Biomatters Ltd., in partnership with the Society for the Study of Evolution (SSE) and the Systematic Biologists (SSB). The iEvoBio 2012 Organizing Committee: Hilmar Lapp, US National Evolutionary Synthesis Center (chair) Robert Beiko, Dalhousie University Nico Cellinese, University of Florida and Florida Museum of Natural History Robert Guralnick, University of Colorado at Boulder Rebecca Kao, Denver Botanic Gardens Ellinor Michel, Natural History Museum, London Nadia Talent, Royal Ontario Museum Andrea Thomer, University of Illinois at Urbana-Champaign (*) iEvoBio and its sponsors are dedicated to promoting the practice and philosophy of Open Source software development (see http://www.opensource.org/docs/definition.php) and reuse within the research community. For this reason, if a submitted talk concerns a specific software system for use by the research community, that software must be licensed with a recognized Open Source License (see http://www.opensource.org/licenses/), and be available for download, including source code, by a tar/zip file accessed through ftp/http or through a widely used version control system like cvs, Subversion, git, Bazaar, or Mercurial. Authors of full talks who cannot meet this requirement at the time of submission should state their intentions, and are advised that the requirement must be met by July 9, 2012, at the latest.

1 0

iEvoBio conference, July 10-11, 2012
by Nico Cellinese 02 Mar '12

02 Mar '12

Dear All, The official website of iEvoBio 2012 is now open (www.ievobio.org). The 2 days conference will be held in conjunction with the annual Evolution meeting in Ottawa on the 10-11 July, 2012. Note that the program includes two exciting challenges and much more! We hope to see you in Canada! Cheers, NIco <><><><><><><><><><><><><><><><><> Nico Cellinese, Ph.D. Assistant Curator, Botany & Informatics Adjunct Assistant Professor, Department of Biology Florida Museum of Natural History University of Florida 354 Dickinson Hall, PO Box 117800 Gainesville, FL 32611-7800, U.S.A. Tel. 352-273-1979 Fax 352-846-1861 http://cellinese.blogspot.com/

1 0

Opened issue 138 regarding apparent incorrect URIs in definitions of several Darwin Core terms
by Steve Baskauf 07 Feb '12

07 Feb '12

I have opened a new issue on the DwC issue tracker http://code.google.com/p/darwincore/issues/detail?id=138 which involves the use in DwC RDF term definitions of apparently incorrect URIs for terms in the Natural Collections Description draft TDWG standard. Steve -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: VU Station B 351634 Nashville, TN 37235-1634, U.S.A. delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235 office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 343-6707 http://bioimages.vanderbilt.edu

1 0

Two issues opened on the DwC issues tracker
by Steve Baskauf 04 Feb '12

04 Feb '12

I have opened two issues on the Darwin Core Google Code issues tracker. Issue 135 (http://code.google.com/p/darwincore/issues/detail?id=135) involves the technical definition of dwc:ResourceRelationship. Issue 136 (http://code.google.com/p/darwincore/issues/detail?id=136) involves the lack of clarity of the identity of the Darwin Core normative (Type 1) documents. Steve Baskauf -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: VU Station B 351634 Nashville, TN 37235-1634, U.S.A. delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235 office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 343-6707 http://bioimages.vanderbilt.edu

1 0