Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check: attribute measurementScale interval vs. ratio accurate #3

Open
eeerika opened this issue Jul 15, 2022 · 3 comments
Open

Check: attribute measurementScale interval vs. ratio accurate #3

eeerika opened this issue Jul 15, 2022 · 3 comments
Labels

Comments

@eeerika
Copy link
Collaborator

eeerika commented Jul 15, 2022

Purpose

This check will look to see if an attribute is accurately described as interval vs. ratio. (can maybe expand this to check to include more measurementScale types?)

Components

  • measurementScale = interval or ratio for the attribute in question
  • the units of the attribute in question
  • list of all units that should definitely be ratio
  • list of all units that should definitely be interval
  • list of units that are edge cases (ie. degree): go to checking the attributeName and/or attributeDescription to make a determination

Result

SUCCESS: if the attribute is accurately described
FAILURE: if the attribute is not accurately described or the unit of the attribute is not found in a list
ERROR: on system error or exception in the check code, representing a bug in the check system

@eeerika eeerika added the check label Jul 15, 2022
@mbjones
Copy link
Member

mbjones commented Jul 15, 2022

@eeerika This looks good. Two notes:

  1. Please note what I said in issue Check: Text file format valid #2 about the use of ERROR -- it shouldn't be for normal failures
  2. While this check is great, it is really a metadata-only check, and so is probably better implemented with the rest of that type of check over in the metadig-checks repo

I propose we might want to define the scope of checks in this metadig-rake package to 1) data quality checks and 2) metadata-data congruency checks .. i.e., stuff that requires opening the data files.

@eeerika
Copy link
Collaborator Author

eeerika commented Jul 19, 2022

Got it, thank you Matt! I did see that other issue regarding the use of ERROR and thought I had phrased that correctly -- what would be a way I could phrase it better here? (by the information cannot be accessed, I had meant due to a system failure or something of the sort)

@mbjones
Copy link
Member

mbjones commented Jul 19, 2022

yeah, I think we're on the same page. I think something like:

ERROR: on system error or exception in the check code, representing a bug in the check system

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants