Skip to content

Conversation

@caufieldjh
Copy link
Contributor

Well, not entirely from scratch. Mostly from KG-OBO.

@caufieldjh
Copy link
Contributor Author

caufieldjh commented May 9, 2022

One difference between assembling PHENIO in KGX is handling of the bridge and equivalency files - these are essentially mappings of one class to another. They could be ingested as xrefs here but:

  • KGX doesn't know how to do that, though having them in SSSOM may help
  • would it make any difference in the graph? We don't want the xrefs to exist as distinct edges, but we do want to recognize equivalency across namespaces.

The NCBI taxonomy slim used by PHENIO also isn't on KG-OBO, so I'm just using the same file here (http://purl.obolibrary.org/obo/ncbitaxon/subsets/taxslim.owl)

@caufieldjh
Copy link
Contributor Author

Trying to use upheno2 in PHENIO, so that should correspond here

@caufieldjh
Copy link
Contributor Author

This unfortunately won't quite work without the upstream processing (i.e., KG-OBO) incorporating some of the changes from #43, namely expanding relations based on subq patterns

@matentzn
Copy link

One difference between assembling PHENIO in KGX is handling of the bridge and equivalency files - these are essentially mappings of one class to another. They could be ingested as xrefs here but:

Good point - Maybe the way forward here is to have Uberon, uPheno and Mondo provide the SSSOM mappings directly to replace the "bridge file" mechanism for this use case.

Maybe a hackathon between a handful of people is in order, as this seems like a general issue we will be facing a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants