By data we mean specimen, observation or checklist datasets published as a Darwin Core Archive and any derivatives. To keep the discussion focused, this does not include pictures or software code.

2012.01.30 – Update to post: technically CC0 is not a license, but a waiver (see comment below).

What we hope to achieve

1. One license for the whole Canadensys community, which is easier for aggregation and sends a strong message as one community.
2. An existing license, because we don’t want to write our own legal documents.
3. An open license, allowing our data to be really used.
4. A clear license, so users can focus on doing great research with the data, instead of figuring out the fine print.
5. Giving credit where credit is due.

Our recommendation

We recommend Canadensys participants to publish their data under Creative Commons Zero (CC0). With CC0 you waive any copyright you might have over the data(set) and dedicate it to the public domain. Users can copy, use, modify and distribute the data without asking your permission. You cannot be held liable for any (mis)use of the data either.

CC0 is recommended for data and databases and is used by hundreds of organizations. It is especially recommended for scientific data and thus encouraged by Pensoft (see their guidelines for biodiversity data papers) and Nature (see this opinion piece). Although CC0 doesn’t legally require users of the data to cite the source, it does not take away the moral responsibility to give attribution, as is common in scientific research (more about that below).

Why would I waive my copyright?

For starters, there’s very little copyright to be had in our data, datasets and databases. Copyright only applies to creative content and 99% of our data are facts, which cannot be copyrighted. We do hold copyright over some text in remarks fields, the data format or database model we chose/created, and pictures. If we consider a Darwin Core Archive (which is how we are publishing our data) the creative content is even further reduced: the data format is a standard and we only provide a link to pictures, not the pictures themselves.

Figuring out where the facts stop and where the (copyrightable) creative content begins can already be difficult for the content owner, so imagine what a legal nightmare it can become for the user. On top of that different rules are used in different countries. Publishing our data under CC0 removes any ambiguity and red tape. We waive any copyright we might have had over the creative content and our data gets the legal status of public domain. It can no longer be copyrighted by anyone.

Can’t we use another license?

Let’s go over the options. Keep in mind that these licenses only apply to the creative aspect of the dataset, not the facts. But as pointed out above, figuring this out can be difficult or impossible for the user. So much so in fact, that the user may decide not to use the data at all, especially if they think they might not meet the conditions of the license.

All rights reserved

The user cannot use the data(set) without the permission of the owner.

Conclusion: Not good.

Open Data Commons Public Domain Dedication and License (PDDL)

There are no restrictions on how to use the data. This license is very similar to CC0.

Conclusion: Perfect, in fact this license was a precursor of CC0, but… it is less well known and maybe not as legally thorough as CC0. CC0 made a huge effort to cover legislation in almost all countries and the Creative Commons community is working hard to improve this even further. Therefore, if you have to choose, CC0 is probably better.

Creative Commons Attribution-NoDerivs (CC BY-ND)

The user cannot build upon the data(set), which is what most data use involves.

Conclusion: Not good, and sadly used by theplantlist.org. Roderic Page pointed this out by showing what cool things he can NOT do with the data.

Creative Commons Attribution-NonCommercial (CC BY-NC)

The user cannot use the data(set) for commercial purposes. This seems fine from an academic viewpoint, but the license is a lot more restrictive than intuitively thought. See: Hagedorn, G. et al. ZooKeys 150 (2011). Creative Commons licenses and the non-commercial condition: Implications for the re-use of biodiversity information.

Conclusion: Not good.

Creative Commons Attribution-ShareAlike (CC BY-SA) or Open Data Commons Open Database License (ODbL)

The user has to share any work based upon the data(set) under a license that is identical or similar to the one used.

Conclusion: Good, but… this can lead to some problems for an aggregator like Canadensys or GBIF: if they are mixing and merging data with different SA licenses, which one do they choose? They might be incompatible.

Creative Commons Attribution (CC BY) or Open Data Commons Attribution License (ODC-By)

The user has to attribute the data(set) in the manner specified by the owner. This condition is also present in the three licenses above.

Conclusion: Good, but… this can lead to impractical “attribution stacking”. If an aggregator or a user of that aggregator is using and integrating different datasets provided under a BY license, they legally have to cite the owner for each and every one of those in the manner specified by these owners (again, for the potential creative content in the data). See point 5.3 at the bottom of this Creative Commons page for a better explanation and this blog post for an example.

But giving credit is a good thing!

Absolutely, but legally enforcing it can lead to the opposite affect: a user may decide not to use the data out of fear of not completely complying with the license (see paragraph above). As hinted at the beginning of this post, CC0 removes the drastic legally enforceable requirement to give attribution, but it does not remove the moral obligation to give attribution. In fact, this has been the common practice in scientific research for many decades: legally, you don’t have to cite the research/data you’re using, but not doing so could be considered plagiarism, which would compromise your reputation and the credibility of your work.

To encourage users to give credit where credit is due, we propose to create Canadensys norms. Norms are not a legal document (see an example here), but a “code of conduct” where we declare how we would like users to use, share and cite our data, and how they can participate. We can explain how one could cite an individual specimen, a collection, a dataset or an aggregated “Canadensys” download. We can point out that our data are constantly being corrected or added to, so it is useful to keep coming back to the original repository and not to a secondary repository that may not have been updated. In addition to that, we can build tools to monitor downloads or automatically create an adequate citation. And with the arrival of data papers – which drafts can now be automatically generated from IPT – data(sets) are really brought into the realm of traditional publishing and the associated scientific recognition.

Conclusion

All this to say that there are mechanisms where both users and data owners can benefit, without the legal burden. CC0 + norms guarantees that our data can be used now and in the future. I for one will update the license for our Université de Montréal Biodiversity Centre datasets. We hope you will join us!

Thanks to the Gregor Hagedorn for his valuable advice on all the intricacies of data licensing.

Darwin Core is a community standard, so anyone can submit ideas, suggestions or corrections via the Darwin Core issue tracker (guidelines to do so can be found here). Minor error corrections can get accepted without peer review, but for more serious changes enough people have to agree (via open commentary and review) before the suggestions are included in the standard. The TDWG Executive Committee has now officially approved a bunch of suggestions (not all) on 16 October 2011 and the standard has been updated in November.

So, what are the most important changes? Well, we have Four Weddings and a Funeral:

4 new terms

The term explanations are mine, specific for specimen data publication. For the official definitions, click on the term.

• dcterms:references: A term borrowed from Dublin Core: a url for the most original or complete information about the record, e.g. the online specimen database record.
• namePublishedInYear: Mainly for checklists: the year in which the scientificName was published.
• georeferencedDate: Erroneously not included in the first version of Darwin Core: the date on which the location was georeferenced.
• identificationVerificationStatus: A number from 0-4 to indicate the extent to which the taxonomic identification has been verified to be correct. The codes can be found here.

1 deprecated term

• occurrenceDetails: This term could only be used for specimens and observations. It has now been replaced by the more general dcterms:references (see above).

This brings the total number of core terms at 159. We have updated our list, please do so as well with your local files or visit the official Darwin Core website.

What is VASCAN?

You don’t know yet? No problem, you can read all about it here:

• VASCAN about page
• Brand new page describing VASCAN as software
• Blog post summarizing VASCAN’s functionalities

Where can I get the code?

• Source code for the webportal
• SQL dump of the MySQL database
• Installation guidelines

Challenges in making VASCAN open source

Even though we always wanted to open-source our code, it is of course developed to fit our needs and setup first. So, our configuration is entangled with the functionality and we have some idiosyncratic code here and there. The challenge was to adapt the current code to support different setups, while keeping most of its original structure. This is what we did:

• All configurations (database connection, data folder, base url, etc.) are now stored in a separate file
• All generated data (images, Darwin Core Archives, indexes, sitemap, etc.) are now stored outside the webapp
• Automatic generation of a “sitemap.xml” for improved indexing by search engines like Google. Access can now be controlled with “robots.txt”.
• Developed an installation function to build the application on your own server. You only need to edit 3 files and building the application is as simple as typing the command “ant war” to create a Java war file.
• Improved documentation and installation guidelines.

As mentioned at the very end of my post about customizing the IPT, I face a problem when I want to install a new version of the GBIF Integrated Publishing Toolkit: installing it will overwrite all my customized files! Luckily Tim Robertson gave me a hint on how to solve this: a shell script to reapply my customization.

Here’s how it works (for Mac and Linux systems only):

Comparing the customized files with the default files

First of all, I need to compare my customized files with the files from the new IPT. They might have changed to include new functionalities or fix bugs. So, I installed the newest version of IPT on my localhost, opened the default files and compared them with my files. Although there are tools to compare files, I mostly did this manually. The biggest change in version 2.0.3 was the addition of localization, for which I’m using a different UI, so I had to tweak some things here and there. It took me about 3 hours until I was satisfied with the new customized IPT version on my localhost.

I also subscribed to the RSS of the IPT Google Code website, to be notified of any changes in the code of “my” files, but I was just using this as a heads-up for coming changes. It is more efficient to change everything at once, when a stable version of IPT is out.

• RSS subscription for any changes in /webapp/WEB-INF/pages/inc, which contains most of my customized files
• RSS subscription for any changes in /webapp/styles/main.css, where I’m commenting out a lot of stuff so my CSS can kick in.

Setting up a file structure

This is how we’ve organized the files on our server. I’ve created a folder called ipt-customization, which contains all my customized files. That way, they can never be overwritten by a new IPT installation, which gets deployed in webapps. The folder also contains a script to apply the customization and a folder to backup the default files currently used by IPT.

• ipt-data
• webapps
  • ipt
• ipt-customization
  • backup-default
  • apply-customization.sh
  • revert-customization.sh
  • header.ftl
  • header_setup.ftl
  • menu.ftl
  • footer.ftl
  • main.css
  • custom.js

Creating the shell script

The apply-customization.sh script works in two steps:

1. Backup the default files, by copying them from IPT to the folder backup-default. The script will ask if I want to overwrite any previously backed up files. The last part is important if I’m running the script several times. In that case I do not want to overwrite the backups with the already customized files.
2. Overwrite the files currently used by IPT with the customized files, by copying them from my ipt-customization folder to the correct folder in IPT

I also created a script revert-customization.sh, to revert the customization to the default IPT, in case something is broken. It moves the backed up files back to IPT:

Running the script

From the command line, I login to my server, navigate to the folder ipt-customization and make my script executable:

I only have to do this the first time I want to use my script. From then on I can use:

To execute the script and customize my new version of IPT!

One of the fundamental rules of running a business is that you have to keep track of your inventory. If you don’t know what’s in the warehouse, or who works for you, you’re not going to get very far as a manager. I think about this every time somebody asks me how many species of flies live in Quebec, or how many species of insects there are in Canada, or how many beetles there are on the island of Montreal. The answer to all three questions is the same – “we don’t know”

Now, as embarrassing as that answer is, it’s not because I didn’t study, or because I can’t be bothered to look it up; it’s because we (“we” being the scientific community) simply DO NOT KNOW.

In 1979 a newly minted group called the Biological Survey of Canada published a book called Canada and its Insect Fauna edited by H.V. Danks, but containing the collected wisdom of the Canadian entomological community. And the purpose of that book was to describe the state of our knowledge of the terrestrial arthropods of Canada. The question was “how many species?”. The answer was “33,672″. End of story? Not a chance. Because the other key number in that list was “32,826″ – that’s a ballpark, top-of-the-head estimate of how many MORE species were living in Canada but remained unrecorded or undescribed. That number is an underestimate.

So, that means that in our own country, where the insects we study are running or flying or crawling or swimming around underfoot, we know less than half of our own species. It’s not because of a fundamental laziness in the entomological community (we’re a hard-working crew!); it’s simply because insects are difficult and diverse, and because there are only so many of us to get the job done.

In the 30-odd years since Canada and its Insect Fauna was published, the Biological Survey of Canada has continued to persevere in documenting the Canadian arthropod fauna. We know a lot more now than we did then, but there’s still a long way to go. New species are sitting preserved in our collections waiting to be discovered and described. New records are running around in our back yards waiting to be documented. Many habitats and regions of Canada have been explored in only a passing way for most arthropod groups. When potential new students come to my lab and ask if there are any good projects to do on taxonomy or phylogeny or inventory of insects around here the first thing I do is pull up a chair for them. They’ll need to get comfy – it takes a while to run through the list.

Nothing gets a job done like spouting optimism, and the entomologists of Canada are, on the whole, a pretty optimistic crew. The job ahead is enormous, but with a great group of people chipping away, we will get the job done. Canada and its Insect Fauna II is the goal we need to aim for.

Why? Because arthropods are intimately connected to every single terrestrial ecosystem in this country. Insects and spiders and mites and their little-known relatives are the mechanics and engineers and drivers and barometers of life on earth and we won’t truly understand, or be able to manage or conserve, those ecosystems until we know who is doing the work.

Our Database of a vascular plants of Canada (VASCAN) is a bit over a year old now (launched on October 22, 2010) and the response has been great so far! The site is averaging 1,850 visits / 20,500 page views a month from over a 100 countries, and is used as a source for vernacular names in Wikipedia and as a tool in the horticultural sector. We thought this would be a good time to summarize some of the things you can do with VASCAN:

What is VASCAN?

You can read all about VASCAN in the about page. If you want a more visual explanation, here’s a presentation about VASCAN (also embedded at the end of this post).

Name search

You can search for any scientific or vernacular name by using the name search. The full search allows you to search on parts of names (starting from the beginning, e.g. Carex ag) and the dropdown box will offer suggestions and provide shortcuts to name pages.

Name pages

A name page interprets the scientific or vernacular name provided in the URL (e.g. http://data.canadensys.net/vascan/name/acer saccharum) and shows relevant information if the name has been found. The system will automatically forward unique synonym and vernacular names to the accepted taxon name, displaying more relevant information (e.g. Acer saccharum subsp. saccharum or Sugar maple), but this functionality can be turned off by appending “?redirect=no” to the link. If a name is linked to multiple taxa, a disambiguation page will be shown (e.g. white maple or Solanum nigrum).

You can use name pages to create dynamic links in your spreadsheet, database or website. Just concatenate “http://data.canadensys.net/vascan/name/” with the name. Please exclude the author and provide the infrageneric or infraspecific rank (“sect.” or “subsp.”) in the name if applicable. It is not necessary to capitalize names correctly or encode space characters as “%20″. An example of a formula you can use in Excel to create links to VASCAN is:

Checklist builder

Interested to know which trees are native in Newfoundland, which genera are introduced in all of the prairies or which Salix species occur in British Columbia, but not in the rest of Canada? You can find it out with the checklist builder, which allows you to combine a set of selection criteria (taxonomic group, habit, distribution, status or a combination of these) and display criteria (ranks to include, sort preference) to create your own customized checklist.

Once your happy with the result you can download the checklist as a simple tab delimited text file or as a standardized Darwin Core archive following the GBIF Global Names Architecture Profile. The latter one also includes the vernacular names and synonyms.

The data are there to be used, which is why we licensed them under the Creative Commons Attribution-ShareAlike 3.0 Unported License, allowing you to build upon our work (read more about it here). You can also download the full database as a Darwin Core archive.

Feedback

If you discover an issue with the data or interface, or you want to send a suggestion, you can do so by clicking the feedback button on the right of every page. So far, the response has been amazing: users have submitted over 700 suggestions for correction, improving the overall quality of the database. All issues are recorded in our public Google Code issue tracker, and we take each one into consideration. You can read more about it here and here.

Summary

And that pretty much sums it up. If you want an overview of the data and functionality, we gave a VASCAN demonstration at the Consortium of Northeastern Herbaria meeting in Philadelphia, June 2011, which is embedded below. Let us know what you think!

You can read the abstract for the contributed talk here.

Useful for the herbarium

The take-home message is that this experiment has paid off really well. Thanks to a great group of volunteers, we were able to collect very useful quantitative metadata for the whole vascular plant collection, with a limited budget (5740$, all staff salary) and in a short time (158 work days, including all the post-counting processing). At 110 specimens per dollar, this was a hundred times cheaper than full digitization (1$/specimen is a number that has been floating around for a number of years).

With the data, curator Luc Brouillet was able to reorganize the herbarium taxonomically, following Christenhusz et al. (2011a) for lycophytes, Smith et al. (2006) for ferns, Christenhusz et al. (2011b) for gymnosperms and APG III (2009) for flowering plants (the same classification as in VASCAN). All folders have now been assigned with a new case/tray number, which will help us tremendously in organizing the move.

With the data, we now also have a much more detailed overview of the collection:

• 628,664 specimens, which is lower than previously estimated. 21.5% are fully digitized.
• 380 families: 82% of all known families
• 5,298 genera
• 6 continents. North America is further divided in Canada, US and Central America. We also have a category for cultivated specimens.

Since we counted the specimens per folder, which is a combination of a case, tray, region, genus and family, we can also calculate their distribution per variable:

Or answer questions like: “How many Rubus specimens do we have from Canada?” Answer: 2921, located in trays A236-07 and A238-04.

Useful for others

We think our metadata is useful for others as well, which is why we published it online:

• As a Google Fusion Table, allowing you to filter, aggregate and visualize the data very quickly, exactly like the embedded pie-chart above.
• As a Darwin Core Archive on the Canadensys repository. Using Darwin Core to express this kind of metadata is a bit experimental, which is why the dataset is not registered with GBIF, but in my opinion it works pretty well. The only term I was missing is one for the folder’s location at the herbarium: caseTrayNumber, which is now shared in dynamicProperties. The big advantage of using a Darwin Core Archive is that I can not only share the dataset, but also the purpose and process behind it (which you can read and download on the IPT page) and in a standardized format (EML); something that is not possible with Google Fusion Tables.

Having the full inventory of the herbarium online will definitely help taxonomists who are interested in loans, but it might also attract the attention of other biodiversity researchers. It could even spark demand driven digitization or set priorities for digitization according to the needs of users outside the taxonomic community (see Berendsohn & Seltmann, 2011), although the granularity of the data (genus, continent) might be too coarse. But at least it’s a first step towards some real numbers, and if we extrapolate our experiment to all 350,000,000 herbarium specimens worldwide (Index Herbariorium) it would “only” cost 3,200,000$ to get a geotaxonomic index for all herbarium specimens! We have updated our page on the Biodiversity Collections Index and Index Herbariorum. So can you!

Downloading and opening the Darwin Core Archive

You can download the entire VASCAN dataset as a Darwin Core Archive from the VASCAN website or our IPT portal. Both link to the same file. You can also generate your own custom subset with the checklist builder.

I download the file and unzip it.

Understanding the archive

To understand the structure of the Darwin Core Archive, I need to take a look at the meta.xml file, shown here without clutter:

I see two interesting files:

• taxon.txt: the core, containing all the taxa in VASCAN
• vernacularname.txt: an extension, containing all the vernacular names for those taxa

A Darwin Core Extension allows to store one-to-many relationships. One record in the core can link to many records in the extension. In this example, one taxon can link to many vernacular names (e.g. in different languages, preferred vs. alternative names, etc.). Just like cores, Darwin Core extensions have to be registered, so others can understand and use them. The vernacular name extension was created by GBIF and is registered here.

I decide to use both files, as I’m also interested in the taxa the vernacular names apply to.

Excel and UTF-8 files

Like all Darwin Core text files, taxon.txt and vernacularname.txt are encoded as UTF-8, which allows the storage of special characters and accents. In this case, this is useful for French vernacular names like “Fougères”.

Sadly though, Excel doesn’t open UTF-8 files correctly by default. I’m using Microsoft Excel 2008 for Mac, and all the following techniques do not work:

• In Finder: Right-click file > Open with > Microsoft Excel
• In Excel: File > Open… > Enable: Text Files > Open > Text Import Wizard
• In Excel: File > Import… > Select: Text File > Import > Choose a file > Get Data > Text Import Wizard

In the Text Import Wizard I can only choose Macintosh, Windows (ANSI) and DOS or OS/2 (PC-8) as the file origin, non of which will shows accents correctly, so my data in Excel looks like this:

In this example my data are stored as tab-separated values (tsv), but the character encoding problem is the same for comma-separated values (csv).

If you know for a fact that the dataset you’re working with doesn’t contain accents or special characters, you can of course use the Text Import Wizard. It has some advantages over the workaround method.

Workaround

The workaround I always use, is to open my UTF-8 file in a decent text editor, like Smultron for Mac (do not use TextEdit) or Notepad++ for PC (both free) and then copy and paste the data in Excel.

1. Open the text file in a text editor
2. Make sure the editor displays the text correctly
3. Select all the data (cmd/ctrl+A)
4. Copy all the data (cmd/ctrl+C)
5. Open an empty spreadsheet in Excel
6. Choose: Format > Cells… > Set category to “Text”
7. Paste everything (cmd/ctrl+V)
8. Choose: Format > Cells… > Set category to “General”
9. Save the file as .xlsx.

In step 6 you force Excel to interpret all the data as text, which avoids annoying date transformations like “2011-03-20″ to “03/20/2011″. Numbers will be interpreted as text too though, so sorting might not work as expected. You can always transform numbers back by using =VALUE(). In step 8 we revert back to “general”, so long cell values will not be shown as “######”. If you do not have dates in your dataset, you could skip step 6 and 8.

Step 9: If you work with an older version of Excel (97-2004) and/or you save your file as .xls, your file will be limited to 65.536 rows.

This workaround method only works for tab-separated values, not for comma-separated values. It is also important to know that copying large chunks of data might slow down or crash your computer. Make sure to save often.

Final thoughts

A lot of people (myself included) use Excel daily: it’s a powerful and user friendly program to manipulate data, but it’s lousy at importing UTF-8 encoded data. I hope this post can help you avoid some of the common pitfalls. If you know an alternative method, please let us know in the comments.

My two text files are now correctly imported in Excel as two sheets/tabs: one for vernacular names and one for taxa. I will explain how you can link both together in another blog post.

One of my responsibilities as the Biodiversity Informatics Manager for Canadensys is to develop a data portal giving access to all the biodiversity information published by the participants of our network. A huge portion of this task can now be done with the GBIF Integrated Publishing Toolkit version 2 or IPT. The IPT allows to host biodiversity resources, manage their data and metadata, and register them with GBIF so they can appear on the GBIF data portal, which are all targets we want to achieve. Best of all, most management can be done by the collection managers themselves.

I have tested the IPT thoroughly and I am convinced the GBIF development team has done an excellent job creating a stable tool I can trust. This post explains how I have customized our IPT installation to integrate it with our other Canadensys websites.

Background

Our Canadensys community portal is powered by WordPress (MySQL, PHP), while our data portal – which before the IPT installation only consisted of the Database of Vascular Plants of Canada (VASCAN) – is a Tomcat application. We are using different technologies because we want to use the most adequate technology for a certain website. WordPress (or Drupal for that matter) is an excellent and easy-to-use CMS, perfect for our community portal, but not suitable for a custom made checklist website like VASCAN. To the user however, both websites look the same:

We do this by using the same HTML markup and CSS for both websites. If you want to learn HTML and CSS, w3schools provides excellent tutorials.

The HTML markup defines elements on a page (e.g. header, menu, content, sidebar, footer) and the CSS stylizes those elements (e.g. their position and color). The CSS is typically stored as one file (e.g. style.css) which is referenced in the <head> section of a page. For dynamic websites, the HTML is typically stored as different files, one for each section of a page (e.g. header.php, sidebar.php). Those files are combined as one page by the server if a page is requested. That way, changing a common element on all pages of a website (e.g. the header) can be done by changing just one file.

All of this also applies to the IPT. Here’s how the IPT looks like without CSS:

Attempt 1 – Editing the CSS and logo

My first attempt at customizing the IPT was at the Experts Workshop in Copenhagen, by changing the CSS and logo only, which you can find in the /styles folder of your IPT installation:

In 15 minutes, my IPT was Canadensys red and had a custom logo:

Attempt 2 – Editing the FreeMarker files

Even though my IPT now had its own branding, it was still noticeably different from the other Canadensys websites. The only way I could change that, was by editing the HTML as well. Luckily, the sections I wanted to change were all stored as FreeMarker files in the /inc folder:

I incorporated the HTML structure I use for the VASCAN website into menu.ftl (including the header, menu, container and sidebar), making sure I did not break any of the IPT functionality.

I started doing the same with main.css by replacing chunks of now unused IPT CSS with CSS I copied over from VASCAN, but I quickly realized that this wasn’t the best option. Doing so would result in 2 CSS files: one for VASCAN and one for IPT, even though both web applications are under the same domain name with a lot of shared CSS. It would be easier if I only had to maintain a single stylesheet, used by both applications.

Attempt 3 – One styles folder for the data portal

I created a /common/styles folder under ROOT, where I placed my single common data portal stylesheet: /common/styles/common.css. This would be the CSS file I could use for IPT and VASCAN. I did the same for my favicon: /common/images/favicon.png.

I added a reference to both files in the header.ftl of my IPT (and VASCAN):

As you can see on the first line, I kept the reference to the default IPT stylesheet: ${baseURL}/styles/main.css (it’s perfectly fine to reference more than one CSS file). This is where I would keep all the unaltered (=default) IPT CSS. In fact, I’m not removing anything from the default IPT stylesheet, I’m only commenting out the CSS that is unused or conflicting:

The advantage of doing so, is that I now easily can compare this commented file with changes in the stylesheet of any new IPT version.

After I had done everything, my IPT now looked like this:

My IPT is now sporting the Canadensys header, footer and sidebar (only visible when editing a resource), making it indistinguishable from the other Canadensys websites. It is also using a more readable font-size (13.5px) and a fluid width.

Closing remarks

I have (re)designed quite a lot of websites, and very often I have been so frustrated with the HTML and CSS that I just started over from scratch. I didn’t have that option here and it wasn’t necessary either. I would like to thank the GBIF development team for creating such an easily customizable tool, with logical HTML and CSS. As a reminder, the whole customization has been done by editing only 5 files:

Important: Remember that installing a new IPT version will overwrite all the customized files, so make sure to back them up! I will try to figure out a way to reapply my customization automatically after an update and post about that experience in a follow-up post. In the meantime, I hope that this post will help others in the customization of their IPT.

Introduction

We are using Specify for the collections at the Université de Montréal Biodiversity Centre and we want to share our experience and guidelines on this page. The collections that will be using Specify are:

• Marie-Victorin Herbarium (MT)
• Ouellet-Robert entomological collection (QMOR)

List of Specify fields we use

The following document is a list of the Specify fields we use per collection. We decided to follow the intended use of the Specify fields as closely as possible, as it will be more understandable for future database managers and to avoid problems with software updates. The file was first introduced in this Canadensys forum post and is updated as we go.

Information about this document

Column 1 & 2: Specify table and field name, logically grouped by colour.

Column 3: Correlating field in the Specify WorkBench.

• White: The field is available in the WorkBench by default.
• Orange: The field is not available in the WorkBench.
• Yellow (added to xml): The field is added by us to the WorkBench by editing the xml files (see below). We hope to add all the fields we need eventually.

Column 4: Indication if the field is visible in the Specify user interface.

• Green (y): The field is visible by default. This may depend on the collection type: botany, insect.
• Green (xml): We added the field to the user interface by editing the xml files. We hope we can add all the fields we need eventually.
• Orange (n): The field is not (yet) visible in the user interface.

Column 5: Explanation and remarks regarding the field or why we choose that field.

Column 6: Field length in Specify. Useful to detect limitations.

Adding fields to the WorkBench

Not all fields of the Specify database are available in the Specify WorkBench (see this outdated list), but most can be added rather easily by editing two XML files. Below you can find the versions we created. To see what fields we have added, see column 3 of Specify fields used at the Université de Montréal Biodiversity Centre (see above).

• /Specify/config/specify_workbench_datamodel
• /Specify/config/specify_workbench_upload_def

How to install a Specify xml file

• Download the file. Select ‘File > Save page as’ if the xml file opens in your browser.
• Go to indicated folder of your Specify installation folder, for example: /Specify/config.
• Rename the current (default) file to ‘<filename>_default.xml’ so it is backed up.
• Move the downloaded (custom) file to the folder.
• Open Specify to check if everything works correctly.

Important: if you update Specify, it will overwrite the custom files with the default ones. Backup the custom files before you update!