-
Notifications
You must be signed in to change notification settings - Fork 26
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
Categorization of KGX transform warnings and errors #338
Comments
Relating a bit to #309 as well (I had the same complains previously) |
Hi @justaddcoffee, I've just attempted a rehabilitation of the KGX error reporting for the 'validate' and 'graph-summary' (PR #364). My gut feeling here is that perhaps I can somehow extend the new mechanism to your use case here. I'll attempt that. |
Great @RichardBruskiewich thanks! |
You may want to consider the linkml validation datamodel (based on SHACL validation datamodel) https://github.com/linkml/linkml-model/blob/main/linkml_model/model/schema/validation.yaml |
@justaddcoffee, PR #338 attempts to implement this use case. |
Resolved by PR #365 |
Is your feature request related to a problem? Please describe.
We are using KGX for kg-obo (Thanks! It's working great.) Basically we are using KGX to transform all OBO ontologies into KGX TSV format - see here.
One challenge is that when you transform >100 ontologies, you get all kinds of errors and warnings. So, which things transformed "correctly" (by some definition), and which did not?
It'd be useful to have KGX transform return errors and warnings that are categorized in some way. For example, when parsing foodon, we see 15 or so warnings to do with bnodes not be handled, which in this case we think is okay, and we can probably upload the transformed graph. In the case of other types of warnings, we might want to not upload the graph.
Describe the solution you'd like
A clear and concise description of what you want to happen.
It'd be awesome to have
kgx.cli.transform
return a dict with errors and warnings binned in some way according to what type of error they are. So we could do something like:Describe alternatives you've considered
Right now we are thinking of just parsing the logs and binning the errors and warnings manually, which is totally doable. We thought though that it might be worth considering having this functionality live in KGX.
Additional context
Per discussion with @cmungall and @caufieldjh
The text was updated successfully, but these errors were encountered: