Quick question – in Specify 7 CSV exports, the header field sometimes includes the name of the table before the name of the field. What determines whether a field will or will not have its table included in the CSV export? It seems like it’s only certain fields – namely ones that have fieldnames that are likely to be duplicated between tables like “FullName”, but many that do not.
Is there a way to change the default headings for fields in CSV exports at this time? For most fields I would want the name to be the fieldname verbatim, but obviously for tree fields, it should be the name of the hierarchy level in the table, not “FullName”.
The current behavior is confusing to public users of the DB, as CSV exports often contain the table names that don’t mean anything to them.
What determines whether a field will or will not have its table included in the CSV export?
There is a hard-coded short list of fields will display the table name before them:
The fields listed above (as of v7.10.2.3) will display the table name, a dash, and the field label, regardless of the table (e.g. Collection Object - ID).
If you include the field localityName in your query, that will instead show the table name (e.g. likely Locality) as the header:
Of course, the most influential condition in the code is the following:
This note explains the behavior, excluding the fields listed above:
If field label consists of a single word, it would be treated as generic (the table name would be used alongside field label).
With the logic described above in mind, this is the expected behavior:
Table Name
Field Name
Field Label
Query Column Heading
Collection Object
catalogNumber
Catalog #
Catalog #
Collection Object
text1
Voucher
Collection Object - Voucher
Collection Object
text2
MorphoSource
Collection Object - MorphoSource
Locality
localityName
Locality Name
Locality
Locality
latitude1
Latitude1
Latitude1
Collecting Event
ID
ID
Collecting Event - ID
As a final note, the logic for tree fields (as you mentioned) is to display Tree Rank - Field rather than display the field alone.
Is there a way to change the default headings for fields in CSV exports at this time? For most fields I would want the name to be the fieldname verbatim, but obviously for tree fields, it should be the name of the hierarchy level in the table, not “FullName”.
This behavior is not currently configurable. However, in most cases, adding a space between two bits of text in the field label will prevent the table name from appearing in query results.
Can you provide a few examples of confusing headings for other users? If we were to add a preference, is this something you would be OK configuring globally (excluding cases like tree ranks)?
Hey Grant,
Thanks for the very thorough reply as always! Would never have guessed the space in the fieldname was what was used to determine this behavior in most cases.
I think it would be neat to be able to configure aliases for certain fields via “templates” for special exports, kind of similar to how we can create DWC files (user uploads a mapping, and then specify can export that type of file by default from then on). This would be useful because different users of the collection might understand different things. I certainly try to format files differently depending on who is requesting data from me, I try to make things as clear and unambiguous as possible, while still making sure to label fields with headers that the person will understand. It might even be cool to have the option to export a “readme” file as well that has the explanations of fields per the database’s schema. I’ve made extensive use of editing the field descriptions so that fieldnames have good descriptions in the tooltips/mouseover text, and I’ve sent these to people in the past to help them understand our data.
To answer your question about what specifically people have found confusing – things like fields in the LocalityDetails table, “LocalityDetails - WaterBody” is not as obvious as “WaterBody”. Likewise for LocalityDetails - coordinateUncertaintyInMeters. But it seems like I can just add spaces to the labels to fix this! It’s hard sometimes being so enmeshed in biodiversity informatics data land to remember that most end users, including scientists, have 0 conception of the structure of these data (i.e. we know LocalityDetails is a table in the database and that these fields must be stored in it, but most end users don’t know what relational databases even are… some might even have trouble resizing the columns in Excel to read the full name of the field.)
The only pernicious issue I see (that can’t be fixed by adding a space) are the formatted fields from particular tables. I have a formatted field in my stock export that I use for responding to inquiries that uses a collection object field formatter that generates the permalink to the lot via bycatalog (e.g. invertebrates.osu.edu/specify/bycatalog/[collectionCode]/[catalognumber]). In the CSV export, it just gets called “Collection Object” but I always rename it to “Permalink”.
All in all, this is a minor issue, and your explanation clears a lot up.