-
Notifications
You must be signed in to change notification settings - Fork 3
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
Refactor: mondo.sssom.config.yml
.subject_prefixes
-> metadata/SOURCE.yml
#483
Comments
@matentzn I created this based on #434 (comment). I agree this is best as a new issue. |
So you're basically suggesting just to rename the file? or extract out the |
Suggesting this one:
Pros:
Cons:
|
If it's as minor as that, got ahead and do it. As long as it doesn't break anything 😄 . I don't have strong opinions |
Ithink |
It wouldn't be a removal; it'd be a refactor. It's a low priority but I'm glad we came to a determination here! Good to know that this is also something that is not expected as some sort of standard SSSOM config. |
Overview
The
subject_prefixes
section ofmondo.sssom.config.yml
exists, as far as I'm aware, in order to tell us (particularly to tell lexmatch), what prefixes pertain to term classes. This allows lexmatch to filter and match only on the correct things. I'm not 100% sure, but I think it might be best to move this information into themetadata/SOURCE.yml
.Questions
1. Redundancy?
This section feels redundant, or perhaps misplaced. There are several places now where prefixes need to be added when we add a new source to Mondo. Some of these are automated by
curies
, e.g. the OBO context JSON and now the SemSQLprefixes.csv
. But I think this needs to be handled separately fromcuries
. Perhaps this isn't really a question. As I'm thinking about it, I don't see where this is redundant. This listsubject_prefixes
represents the subsets of prefixes in an ontology (classes) that we want to do matching on.2. Best location?
I was thinking that maybe the best location for this would be in each ontology's
metadata/*.yml
file. We have aprefix_map
and abase_prefix_map
(subset ofprefix_map
that is 'owned' by the ontology) there. It would seem to me that a good place to put this. Isn't it the case that the prefixes we have insubject_prefixes
inmondo.sssom.config.yml
represent things we want to match against, which would only be classes, right? If that's the case, then should we not have aclass_prefixes
section inmetadata/*.yml
and put this there instead? Intuitively also that just feels like the best location to me. Though if this is only going to be used bymondo.sssom.config.yml
, maybe it is indeed best there. Not saying this is a big priority; if it's not broke, don't fix it, as the saying goes. Thoughts?The text was updated successfully, but these errors were encountered: