Draft McDonald's Omega

[strengejacke]

No description provided.

[codecov]

Codecov Report

Attention: 30 lines in your changes are missing coverage. Please review.

Comparison is base (76d02f1) 56.64% compared to head (9d115eb) 56.30%.

❗ Current head 9d115eb differs from pull request most recent head cf9b7bd. Consider uploading reports for the commit cf9b7bd to get more accurate results

Files	Patch %	Lines
R/mcdonalds_omega.r	75.86%	21 Missing ⚠️
R/check_itemscale.R	64.00%	9 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #669      +/-   ##
==========================================
- Coverage   56.64%   56.30%   -0.35%     
==========================================
  Files          84       85       +1     
  Lines        6039     6108      +69     
==========================================
+ Hits         3421     3439      +18     
- Misses       2618     2669      +51     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[strengejacke]

@easystats/core-team Anyone an idea, if it's ok to "borrow" some code from MBESS? See my @note I added to the docs:

#' @note The code is based on the `MBESS::ci.reliability()` function, which
#' is licensed under the GPL-2|GPL-3 license. Credits go to Sunthud Pornprasertmanit
#' and Ken Kelley.

I adopted (and modified) code for constructing the lavaan-formula and CI from MBESS::ci.reliability().

[DominiqueMakowski]

shouldn't we call it omega_mcdonalds() in case there are others omega_* ? No strong opinion though

[strengejacke]

I think as reliability index, there's just the McDonald's Omega - it's just that there are different versions like normal, hierarchical, or for categorical data. That could be altered using a type argument or similar.

[bwiernik]

Almost no one uses "McDonalds" in the name here -- they just say "omega", "omega hierarchical", or "omega subscale".

GPL-licensed code isn't compatible with our license, so we can't include it. We would need to write our own function (I can do that if we decide to include this.)

I'm leery about including a function for omega like this one. The purpose of omega is that it is a model-based reliability a model based reliability estimator. The estimate is specific to the measurement model assumed for the items. This function assumes a single latent factor model--it doesn't work if a different sort of factor model or SEM is used (eg, multiple traits, a bifactor model, etc).

The practical difference between omega and alpha for a single factor model is usually negligible (alpha is equivalent to omega computed on a single factor model with all loadings constrained to equal, but note that alpha doesn't assume a specific measurement model like omega does).

I'm concerned that if we just include an omega() function like this that users will assume it always applies and use it even when their measurement model is very different. The push to use omega over alpha is more about being by more thoughtful about measurement assumptions than just substituting a different calculation with the same mindless adoption

If we include an omega function, I think we need to at least include both a lavaan model method to compute omega for the specified model in addition to a data frame method that uses a single factor model like here. The output should emphasize the model the value is computed for.

For comparison, the psych::omega() function fits an bifactor model with a specified number of group factors.

[strengejacke]

Almost no one uses "McDonalds" in the name here -- they just say "omega", "omega hierarchical", or "omega subscale".

ok, I thought it would be in line with cronbachs_alpha(), and we avoid name conflicts with the psych-package.

I'm leery about including a function for omega like this one. The purpose of omega is that it is a model-based reliability a model based reliability estimator. The estimate is specific to the measurement model assumed for the items. This function assumes a single latent factor model--it doesn't work if a different sort of factor model or SEM is used (eg, multiple traits, a bifactor model, etc).

I was thinking of that estimate as a measure of internal consistency of a scale (like Cronbach's Alpha), that's why I thought it doesn't matter much if omega is usually a model based reliability estimator? See https://tidsskriftet.no/en/2022/08/medicine-and-numbers/internal-consistency-alpha-omega
And this paper (https://www.tandfonline.com/doi/full/10.1080/21501378.2021.1940118) suggests that the way how omega is calculated is suitable? The current implementation of mcdonalds_omega() assumes that all variables (items) in the provided data frame belong to one scale.

I'm concerned that if we just include an omega() function like this that users will assume it always applies and use it even when their measurement model is very different.

What do you mean by this? Does this matter when I just want to check internal consistency of a scale?

[strengejacke]

After revisiting this PR, I think I understand your concerns, Brenton. Let's close this.