We're going to have to do prefix normalization again, so perhaps it should:
Be in its own repo, OR
Be part of an existing repo, e.g., prefixmaps, AND/OR
Operate as a microservice, potentially on KG-Hub (suggested by @sierra-moxon)
So why not just use the functions in curies and prefixmaps?
The IRIs/CURIEs used in KG-OBO and other graph collections (see KG-Bioportal) are noisy - we anticipate any ID needs to undergo the following checks:
Is this an IRI or a CURIE?
If it's an IRI, do we have a corresponding CURIE prefix?
If it's a CURIE, is it using our preferred prefix?
If we can't find a corresponding prefix, is this an alternative form?
This requires one-to-many maps from IRI forms to CURIE prefixes plus lists of alternative prefixes. Alternatively, some cases (e.g., http vs. https; invalid prefixes like file:) may be handled outside the maps.
We're going to have to do prefix normalization again, so perhaps it should:
prefixmaps
, AND/ORSo why not just use the functions in
curies
andprefixmaps
?The IRIs/CURIEs used in KG-OBO and other graph collections (see KG-Bioportal) are noisy - we anticipate any ID needs to undergo the following checks:
file:
) may be handled outside the maps.