Statistics Panel for Specify 7

Dear Specificians –

We are prospecting for ideas and suggestions for a new collections statistics panel we will be releasing soon in a Specify 7 update.

We would value your input as to which stats you would like included by default in the panel. We know how useful it can be to have a quantitative description of your collection’s data and processing activities as documentation for year-end reports, proposals, progress assessment, etc.

We started with stats shown in Specify 6 as a model, but it is only a baseline. We have great flexibility for summarizing data–almost any query and query result you can imagine using Specify can be implemented as a ‘standing’ stat.

In the future, we plan to expand the panel to include stats on network-based events and remote data objects related to your collection records (think Digital Extended Specimen), but for this release we are scoping stats to information in the collection database. We also planning to include charts and additional ways to visualize your stats.

Below is a screen share of our work-in-progress basic panel. We know we can make it more useful and relevant with community input. What else would you like to see here?

Many thanks in advance for your creative thoughts and responses.

“Facts are stubborn things, but statistics are pliable.” ― Mark Twain

Maybe we should call it “Collection Facts”.

One default statistic that would be useful to add would be percentage imaged or number of specimens with an image attachment. For NSF reporting, we are most interested in whether or not a specimen record has an image attached, but this information can be hard to extract from query results. If multiple images are attached to a single specimen record, each image attachment appears as a separate item in query results.
It would be ideal to have a Collection Statistics panel that is flexible, allowing users to define, modify, and save their Collection Statistics or Charts.

1 Like

Some ideas for comment:

  1. Number of attachments - possibly broken down by table
  2. What about other interactions - number of accessions, borrows, gifts, permits, exchanges
  3. Number of sequences
  4. Number of citations
  1. Number of attachments - possibly broken down by table

We already have this on the Attachments page (the picklist for filtering attachments by table shows counts)

Yes, aware of that but might be nice to see these as part of the summary stats too. Should be “easy”

It would be useful to have other interactions statistics - not just Loans. This would therefore include Accessions, Permits, Exchanges (In & Out), Information Requests. Can it also be filtered on a date range - this would be valuable for reporting requirements.

Would it be possible for users to define a default/customisable Collection Statistics page relevant to their needs?

Statistics Panel proposals:

  • show also the more important ones on the Welcome screen by default (Holdings, Loans, Computerization panels)

  • Panel “Holdings”: make items clickable as link so that all records are opened in a form view (it has also proposed to have this function function as a data view menu (see "Data Views" menu · Issue #2047 · specify/specify7 · GitHub)

  • Computerization panel: could also include item “total number of CO”, make it a link, but is somewhat redundant with proposal above

  • Computerization panel (for CO records): please make this query on “CO Timestamp created” and not as currently “Date catalogued”, some users do not use the latter field; please make items clickable links so that these records are shown in form view

Entirely second these 4 additions, especially #2 (and especially exchanges) as emphasized by @DLewis.
Regarding Locality/Geography stats. Would countries (an perhaps other administrative entities) be “represented” as with taxa… not just the ones present in the tree? The former would be more useful.

Also:
Would it be possible to quantify/estimate data quality in one’s collection (certainly for a much later day – surely not easy)? i.e., how many records comply with standards above some pre-established/consensus quality threshold. At least for some tables; Taxonomy should probably be the easiest. This can be a useful predictor of how many of one’s records should be excluded from aggregators.

Hi

Just a suggestion that including the number of specimens at MIDS levels 1 & 2 might be interesting. The MIDS specification is not quite complete and it’s not completely straightforward but it would be good to start looking at it.

All the best

Elspeth

Just a thought about statistics:
It would be nice to have a user-friendly way to export these statistics to several common file format. (as a spreadsheet, pdf,…)
Thanks!

Can you give me a use case for your #2 here? Why would you want to see all records listed in form view? Most common workflows have users creating lists of records for various purposes - CO by locality or taxa but there are very few occasions where you want to just view everything in your collection.

Hi Andrew,
many of you users - me included - wish to have a rapid view of all Collection Object records without having to make a query.
This assures you that all records are still there. Most of our users are more familiar with Filemaker databases and in this system you always start with a view of all records. It is much more intuitiv for people who do not have an informatics background. They do not understand or accept why Specify upon starting the application is not presenting them what is available as collection object records.

However, it is also important to have all records displayed for our daily control routine. Before starting to add new records, we always check what are the last records that have been added and if there are errors. The users of each collection should control each other. So, by examining the last records we also know were we stoppend our work during the previous session/day. It is tiresome to create or call a query for this.

Another important point for the statistics panel I wish to repeat is point #3. We - and cerrtainly others too - do not use the fields “Cataloguer” and “Date catalogued” and the statistics panel do not work for us. These fields are redundant with the automatically generated fields “created by” and “timestamp created”. So there is no need to duplicate this.

Kind regards,
Peter

1 Like