These functions can be used to predefine your own reference to be used in as.mo() and consequently all mo_* functions like mo_genus() and mo_gramstain().
This is the fastest way to have your organisation (or analysis) specific codes picked up and translated by this package.
set_mo_source(path) get_mo_source()
Arguments
| path | location of your reference file, see Details. Can be |
|---|
Details
The reference file can be a text file separated with commas (CSV) or tabs or pipes, an Excel file (either 'xls' or 'xlsx' format) or an R object file (extension '.rds'). To use an Excel file, you will need to have the readxl package installed.
set_mo_source() will check the file for validity: it must be a data.frame, must have a column named "mo" which contains values from microorganisms$mo and must have a reference column with your own defined values. If all tests pass, set_mo_source() will read the file into R and export it to "~/.mo_source.rds" after the user specifically confirms and allows that this file will be created. For this reason, this function only works in interactive sessions.
The created compressed data file "~/.mo_source.rds" will be used at default for MO determination (function as.mo() and consequently all mo_* functions like mo_genus() and mo_gramstain()). The location of the original file will be saved as an R option with options(mo_source = path). Its timestamp will be saved with options(mo_source_datetime = ...).
The function get_mo_source() will return the data set by reading "~/.mo_source.rds" with readRDS(). If the original file has changed (by checking the aforementioned options mo_source and mo_source_datetime), it will call set_mo_source() to update the data file automatically.
Reading an Excel file (.xlsx) with only one row has a size of 8-9 kB. The compressed file created with set_mo_source() will then have a size of 0.1 kB and can be read by get_mo_source() in only a couple of microseconds (millionths of a second).
How to setup
Imagine this data on a sheet of an Excel file (mo codes were looked up in the microorganisms data set). The first column contains the organisation specific codes, the second column contains an MO code from this package:
| A | B | --|--------------------|--------------| 1 | Organisation XYZ | mo | 2 | lab_mo_ecoli | B_ESCHR_COLI | 3 | lab_mo_kpneumoniae | B_KLBSL_PNMN | 4 | | |
We save it as "home/me/ourcodes.xlsx". Now we have to set it as a source:
set_mo_source("home/me/ourcodes.xlsx") #> NOTE: Created mo_source file '~/.mo_source.rds' from 'home/me/ourcodes.xlsx' #> (columns "Organisation XYZ" and "mo")
It has now created a file "~/.mo_source.rds" with the contents of our Excel file. Only the first column with foreign values and the 'mo' column will be kept when creating the RDS file.
And now we can use it in our functions:
as.mo("lab_mo_ecoli") #> [1] B_ESCHR_COLI mo_genus("lab_mo_kpneumoniae") #> [1] "Klebsiella" # other input values still work too as.mo(c("Escherichia coli", "E. coli", "lab_mo_ecoli")) #> [1] B_ESCHR_COLI B_ESCHR_COLI B_ESCHR_COLI
If we edit the Excel file by, let's say, adding row 4 like this:
| A | B | --|--------------------|--------------| 1 | Organisation XYZ | mo | 2 | lab_mo_ecoli | B_ESCHR_COLI | 3 | lab_mo_kpneumoniae | B_KLBSL_PNMN | 4 | lab_Staph_aureus | B_STPHY_AURS | 5 | | |
...any new usage of an MO function in this package will update your data file:
as.mo("lab_mo_ecoli") #> NOTE: Updated mo_source file '~/.mo_source.rds' from 'home/me/ourcodes.xlsx' #> (columns "Organisation XYZ" and "mo") #> [1] B_ESCHR_COLI mo_genus("lab_Staph_aureus") #> [1] "Staphylococcus"
To delete the reference data file, just use "", NULL or FALSE as input for set_mo_source():
set_mo_source(NULL) # Removed mo_source file '~/.mo_source.rds'.
If the original Excel file is moved or deleted, the mo_source file will be removed upon the next use of as.mo(). If the mo_source file is manually deleted (i.e. without using set_mo_source()), the references to the mo_source file will be removed upon the next use of as.mo().
Stable lifecycle
The lifecycle of this function is stable. In a stable function, major changes are unlikely. This means that the unlying code will generally evolve by adding new arguments; removing arguments or changing the meaning of existing arguments will be avoided.
If the unlying code needs breaking changes, they will occur gradually. For example, a parameter will be deprecated and first continue to work, but will emit an message informing you of the change. Next, typically after at least one newly released version on CRAN, the message will be transformed to an error.
Read more on our website!
On our website https://msberends.github.io/AMR you can find a comprehensive tutorial about how to conduct AMR analysis, the complete documentation of all functions (which reads a lot easier than here in R) and an example analysis using WHONET data. As we would like to better understand the backgrounds and needs of our users, please participate in our survey!