- IPT - lists.gbif.org

Re: [IPT] Action: check options - how to do when you have more than one sampling method for the same plant plot
by Andrea Hahn 21 Jul '20

21 Jul '20

Hi Rui, I would like to advise against creating duplicates for this purpose. For one thing, it is difficult for users to understand how (and why) to pull the information together again if it appears in two separate records. Assuming that both measurements were taken at the same location as well as time: have you considered using the "ExtendedMeasurementsOrFacts" extension (https://tools.gbif.org/dwca-validator/extension.do?id=http://rs.iobis.org/o… It seems to cover your scenario. Thanks, Andrea --- Andrea Hahn (ahahn(a)gbif.org) Head of Data Products GBIF Secretariat Universitetsparken 15 DK-2100 Copenhagen, DENMARK Tel: +45-35 32 14 91 Fax: +45-35 32 14 80 URL: http://www.gbif.org -----Original Message----- From: IPT <ipt-bounces(a)lists.gbif.org> On Behalf Of Rui Figueira Sent: Monday, 20 July, 2020 18:34 To: ipt(a)lists.gbif.org Subject: Action: check options - [IPT] how to do when you have more than one sampling method for the same plant plot Dear all, One of our publishers is preparing an event based dataset with plant surveys, where two measurements were taken at each location: a Braun Blanquet Scale value and % of coverage. The normal option to create this dataset would be to make two event records for each plot, one for each survey method. This allows to preserve all original data, but will result in two occurrences for the same species at the same plot. The other option would be to report only one of the survey methods, avoiding occurrence duplication, but not preserving data for the other method. Would anyone have a suggestion how to prepare the dataset, so that it keeps values for both methods and does not create duplication of occurrences? Or the duplication is not an issue, and we should publish data for both methods? Thanks, Rui -- ------------------ Rui Figueira Coordenador do Nó Português do GBIF ruifigueira(a)isa.ulisboa.pt Instituto Superior de Agronomia Herbário Tapada da Ajuda, 1349-017 Lisboa, Portugal Tel. +351 213653165 | Fax. +351 213653195 http://www.gbif.pt http://www.isa.ulisboa.pt _______________________________________________ IPT mailing list IPT(a)lists.gbif.org https://lists.gbif.org/mailman/listinfo/ipt

1 0

IPT mailing list submissions
by Denis Beina 09 Jul '20

09 Jul '20

IPT mailing list submissions Denis Beina, Ph.D. ***************Directeur de CabinetMinistère de l'Enseignement Technique et de l'AlphabétisationBP.: 35, Bangui, République CentrafricaineTél.: +23672028881 +23675048024Skype; denisbeinaWhatsapp: +23672028881 ;

1 0

IPT fields mapped to GBIF API download fields?
by Simpson, Annie 08 Jul '20

08 Jul '20

I'm new to the list, and though I've looked at the archives I find them hard to maneuver (very nested; can't just 'search on page'). Can anyone point me to a reference/lookup table that maps the IPT field names and content to the names and content of the fields that are currently within a GBIF download (.xlsx example is attached, with 241 columns)? Thanks if you can, and may you be well, Annie Simpson, biologist and information scientist BioFoundational Data Team Science Analytics & Synthesis Program U.S. Geological Survey 12201 Sunrise Valley Dr. Mailstop 302 Reston VA 20192 asimpson(a)usgs.gov +1 703-648-4281 https://orcid.org/0000-0001-8338-5134

4 6

New IPT Warning appearing also in Colombia's IPT
by Camila Andrea Plata Corredor 05 Jun '20

05 Jun '20

Dear all, We are having the same problem in one of our IPTs ( https://ipt.biodiversidad.co/iavh/) the error shows the same unidentified ID. We are also looking for some advice to fix the issue. - Advertencias en el inicio del IPT. Para obtener ayuda adicional en el diagnostico del(los) problema(s), por favor véase la actividad del sistema. Despues de corregir el(los) problema(s), por favor reinice su servidor web. - *Couldn't load registered organisation 625a5522-1886-4998-be46-52c66dd566c9 from Registry: https://gbrds.gbif.org <https://gbrds.gbif.org>.* Best! Camila Plata SiB Colombia El jue., 4 jun. 2020 a las 7:00, <ipt-request(a)lists.gbif.org> escribió: > Send IPT mailing list submissions to > ipt(a)lists.gbif.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gbif.org/mailman/listinfo/ipt > or, via email, send a message with subject or body 'help' to > ipt-request(a)lists.gbif.org > > You can reach the person managing the list at > ipt-owner(a)lists.gbif.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPT digest..." > > > Today's Topics: > > 1. New IPT Warning appearing (Gamble, Beth) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 Jun 2020 14:39:55 +0000 > From: "Gamble, Beth" <GambleB(a)si.edu> > To: "ipt(a)lists.gbif.org" <ipt(a)lists.gbif.org> > Subject: [IPT] New IPT Warning appearing > Message-ID: > < > CH2PR12MB41506D5ED968CB72B3203696D8880(a)CH2PR12MB4150.namprd12.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > Hello, > > Our IPT is currently producing a warning message: > > IPT startup warnings. For additional help diagnosing the problem(s), > please see logs. After fixing the problem(s), please restart your web > server. > Registry:https://gbrds.gbif.org > から登録した機関625a5522-1886-4998-be46-52c66dd566c9をロードすることができませんでした。 > Не могу загрузить зарегистрированную Организацию из > 625a5522-1886-4998-be46-52c66dd566c9 Registry: https://gbrds.gbif.org. > 無法從登錄 https://gbrds.gbif.org > 載入已註冊之單位組織：625a5522-1886-4998-be46-52c66dd566c9。 > Couldn't load registered organisation 625a5522-1886-4998-be46-52c66dd566c9 > from Registry: https://gbrds.gbif.org. > > I’m kind of at a loss as to how to resolve. No organizations have been > changed in our IPT instance as far as I am aware. Thanks for any feedback > on how to resolve. > > https://collections.nmnh.si.edu/ipt > > Thanks, > Beth :-) > > Beth Gamble > Senior Systems Analyst > IT – Informatics Office > w 202.633.0851 e gambleb(a)si.edu<mailto:gambleb@si.edu> > > SMITHSONIAN INSTITUTION<http://www.si.edu/> > NATIONAL MUSEUM OF NATURAL HISTORY<http://naturalhistory.si.edu/> > Facebook<https://www.facebook.com/nmnh.fanpage/> | Twitter< > https://twitter.com/NMNH> | Instagram< > https://www.instagram.com/smithsoniannmnh/> > > >

2 1

New IPT Warning appearing
by Gamble, Beth 04 Jun '20

04 Jun '20

Hello, Our IPT is currently producing a warning message: IPT startup warnings. For additional help diagnosing the problem(s), please see logs. After fixing the problem(s), please restart your web server. Registry:https://gbrds.gbif.orgから登録した機関625a5522-1886-4998-be46-52c66dd566c9をロードすることができませんでした。 Не могу загрузить зарегистрированную Организацию из 625a5522-1886-4998-be46-52c66dd566c9 Registry: https://gbrds.gbif.org. 無法從登錄 https://gbrds.gbif.org 載入已註冊之單位組織：625a5522-1886-4998-be46-52c66dd566c9。 Couldn't load registered organisation 625a5522-1886-4998-be46-52c66dd566c9 from Registry: https://gbrds.gbif.org. I’m kind of at a loss as to how to resolve. No organizations have been changed in our IPT instance as far as I am aware. Thanks for any feedback on how to resolve. https://collections.nmnh.si.edu/ipt Thanks, Beth :-) Beth Gamble Senior Systems Analyst IT – Informatics Office w 202.633.0851 e gambleb(a)si.edu<mailto:gambleb@si.edu> SMITHSONIAN INSTITUTION<http://www.si.edu/> NATIONAL MUSEUM OF NATURAL HISTORY<http://naturalhistory.si.edu/> Facebook<https://www.facebook.com/nmnh.fanpage/> | Twitter<https://twitter.com/NMNH> | Instagram<https://www.instagram.com/smithsoniannmnh/>

1 0

GBIF.org supports recordedByID and identifiedByID
by Tim Robertson 06 Apr '20

06 Apr '20

Dear all Last week GBIF.org enabled two new filters to allow search using recordedByID and identifiedByID fields. Datasets such as iNaturalist support the use of ORCID IDs for people. Those users who have linked their account in iNaturalist can now find records in GBIF using their ORCID - e.g.: https://www.gbif.org/occurrence/search?recorded_by_id=https:~2F~2Forcid.org… Similarly, users in the Danish SvampeAtlas can find records they've submitted but were identified by a particular user: https://www.gbif.org/occurrence/taxonomy?recorded_by_id=https:~2F~2Forcid.o… We recommend using well-controlled identifiers for people / agents, such as ORCID and WikiData identifiers, but will index any value filled in. The fields are included in the DwC-A downloads from GBIF.org searches. We now plan to enable this for data publishers using the IPT. I have made a new release of the Occurrence core schema and enabled it for IPTs in TEST mode only [1]. I would appreciate if an IPT user could help test this with me. Using an IPT that is in test mode: 1) In Admin / Core and Extensions you should be able to hit "update" 2) Following update, you should see a note on "Occurrence" stating that the fields are available 3) You can then map occurrence records using this term 4) If you register the test dataset in GBIF it should index on https://www.gbif-uat.org and the searches can be done in the test environment. If someone is able to test this, please can you reply to all so we know it is underway? Many thanks, Tim [1] http://rs.gbif.org/sandbox/core/dwc_occurrence_2020-03-30.xml

2 3

IPT mailing list submissions
by Denis Beina 04 Apr '20

04 Apr '20

1 0

coreid (lowercase "i") vs coreId in meta.xml - schema validation
by Stoner, Dan F 13 Dec '19

13 Dec '19

I found some oddities and I am not exactly sure where to go next. We are noticing the following while processing meta.xml in darwin core archives produced by IPT (and other servers): Schema validation failed, continuing unvalidated XMLSyntaxError: Element '{http://rs.tdwg.org/dwc/text/}coreid': This element is not expected. Expected is ( {http://rs.tdwg.org/dwc/text/}coreId ) It seems like most consumers are not actually validating meta.xml using the schema, and the producers are generating files out of compliance with the schema. Most of the Darwin Core archives I have manually inspected and tried to validate contain meta.xml with lowercase "i" in coreid despite the Standard indicating capital "I" in coreId. I poked at the GBIF Darwin Core Validator 3 code repo and found this: schema.meta=https://raw.githubusercontent.com/tdwg/dwc/master/standard/docu… The first link leads to 404, the second leads to an xsd that contains the proper coreId. So maybe the Validator is not being "strict" about validation against the schema? Digging around I find some "historic" evidence of changes that occurred when tdwg migrated from google code to github and moved their services around, and that GBIF might have "grabbed a copy" from somewhere while waiting for the public site to become available again. The current "published" schema contains coreId: http://rs.tdwg.org/dwc/text/tdwg_dwc_text.xsd The current "master" branch contains coreId: https://github.com/tdwg/dwc/blob/master/docs/text/tdwg_dwc_text.xsd The "gh-pages" branch (one would think this is being used to generate the website, but apparently not) includes the lowercase coreid: https://github.com/tdwg/dwc/blob/gh-pages/text/tdwg_dwc_text.xsd So I am wondering why the GBIF Validator isn't noticing this. And why is IPT generating meta.xml that does not agree with the schema? Reference: http://rs.tdwg.org/dwc/text/ 2.1.2 Elements Element Description <core> An <archive> must contain exactly one <core> element, representing the data entity (the actual file and its column header mappings to Darwin Core terms) upon which records are based. If extensions are being used, each record in the core data must have a unique identifier. The field for this identifier must be specified in an explicit <id> field in order to associate extension records with the core record. <extension> An <archive> may define zero or more <extension> elements, each representing an individual extension entity directly related to the core. In addition to the general file attributes described below, every extension entity must have an explicit <coreId> field to relate the extension record to a row in the core entity. The extension itself does not have to have a unique ID field and many rows can point to the same core record. Thanks! Dan Stoner iDigBio / ACIS Laboratory University of Florida

2 2

FW: [datacite-allusers] Delays in DOI registrations and updates
by Tim Robertson 02 Aug '19

02 Aug '19

Dear GBIF community Please be aware of this communication from DataCite which will likely cause some disruption on GBIF services with relation to DOI issuing. Many thanks, Tim From: Martin Fenner <martin.fenner(a)datacite.org> Reply-To: "allusers(a)datacite.org" <allusers(a)datacite.org> Date: Friday, 2 August 2019 at 08.22 To: DataCite Allmembers <allmembers(a)datacite.org>, DataCite Allusers <allusers(a)datacite.org> Subject: [datacite-allusers] Delays in DOI registrations and updates Dear DataCite members and users, processing of DOI registrations is currently delayed by up to 12 hours, affecting registration in the handle system and inclusion in the search index. This is caused by an unusually very large number of maintenance jobs running in our system, and we expect this to be resolved by the end of the day. This is a delay in processing, all DOI registrations and updates are successfully captured by our system. Requesting or searching DOI metadata is not affected. Please check https://status.datacite.org for updated status information, or subscribe to email updates at this site. The reason for the very large number of maintenance jobs is two important updates to better handle malformed dates in DOI metadata and to prepare for affiliation identifier support in the upcoming schema 4.3. The load on the system for these two tasks is much higher than expected, causing the delays described above. I sincerely apologize for the inconvenience this is causing, and going forward we will be better in giving advance notice with scheduled maintenances for situations like this. What is happening today is unrelated to the service incident we reported on July 24 (https://status.datacite.org/incidents/d00gnm05ps3k) That incident was caused by a very high number (> 1 million in 24 hours) of DOI registration requests by a single client, temporarily overloading the system. To prevent this from happening in the future, we have this Monday implemented rate-limiting of 3,000 requests per IP address within 5 min, which translates to 10 requests per second or 36,000 requests per hour per IP address. Please reach out to support(a)datacite.org<mailto:support@datacite.org> if you need higher rate-limits temporarily or generally, and we can adjust the rate-limits for your IP addresses. This is the first time we implemented rate-limiting, but we had to take this step to make sure DOI registrations for all users are not affected by high numbers of requests by a single user. We have also increased the number of servers and improved monitoring to better handle these kinds of situations in the future. Please reach out to me via support(a)datacite.org<mailto:support@datacite.org> if you have any comments or feedback. Kind regards, Martin Fenner -- Martin Fenner DataCite Technical Director http://orcid.org/0000-0003-1419-2405 -- You received this message because you are subscribed to the Google Groups "DataCite Allusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to allusers+unsubscribe(a)datacite.org<mailto:allusers+unsubscribe@datacite.org>. To view this discussion on the web visit https://groups.google.com/a/datacite.org/d/msgid/allusers/CAG9q6AbF31-QENqc…<https://groups.google.com/a/datacite.org/d/msgid/allusers/CAG9q6AbF31-QENqc…>.

1 0

New IPT version: 2.4.0.
by Matthew Blissett 01 Aug '19

01 Aug '19

Dear IPT users, A new version of the IPT has been released, version 2.4.0. This version includes security updates from Struts and Jackson (code libraries the IPT uses). For this reason, all users should upgrade. It also includes support for DataCite's new API for issuing DOIs, since the old API has been switched off. The new version is available for download herehttps://repository.gbif.org/content/groups/gbif/org/gbif/ipt/2.4.0/ipt-… <http://repository.gbif.org/content/groups/gbif/org/gbif/ipt/2.3.4/ipt-2.3.4…> . New CentOS packages and Docker containers have also been generated, please see https://github.com/gbif/ipt/blob/master/package/rpm/README.md and https://github.com/gbif/docker-ipt. Please read the release notes, particularly if you are not upgrading from the previous release, 2.3.6:https://github.com/gbif/ipt/wiki/IPTReleaseNotes233.wiki Sincerely, Matthew Blissett GBIF Secretariat

2 3