Skip to content
This repository has been archived by the owner on Oct 28, 2022. It is now read-only.

Ontology Source Identification #695

Open
david4096 opened this issue Aug 22, 2016 · 2 comments
Open

Ontology Source Identification #695

david4096 opened this issue Aug 22, 2016 · 2 comments

Comments

@david4096
Copy link
Member

In #621 @mcourtot mentions

With respect to the ontology source identification. At the moment, there is:
Ontology source name - the name of ontology from which the term is obtained, e.g. 'Human Phenotype Ontology': I think this may give rise to multiple values for the same resource, e.g., 'Human Phenotype Ontology', 'HP', 'HPO' which is IMO not desirable. A solution to this is using a registry such as the ones @mellybelly mentions above - it also has the advantage that we can add pretty much whichever information we want to this registry, e.g. if the CURIE prefix expansion changes we can update that seamlessly (e.g. we have been using http://purl.bioontology.org/ontology/SNOMEDCT/{sctid} but then decide to update to the official SNOMED URIs as per http://doc.ihtsdo.org/download/doc_UriStandard_Current-en-US_INT_20140527.pdf, and it should be updated to http://snomed.info/sct/{sctid})
We could then have Ontology source name - the name of ontology from which the term is obtained, e.g. 'HP', as taken from the GA4GH resources registry.

This issue is meant to capture further discussion on Ontology Term representations, specifically, a discussion regarding how to control the vocabulary of source_name. @mbaudis @cmungall @mellybelly

@mbaudis
Copy link
Member

mbaudis commented Aug 26, 2016

I obv. support a mechanism for correct ontology source identification. However, should be a general mechanism, not being bound to a specific registry (e.g. local implementations may have their own instances; any given registry/service should be considered transient in the long run).

Suggestions, please?

@mcourtot
Copy link

mcourtot commented Sep 2, 2016

We discussed this with @helenp, @cmungall and @simonjupp and would like to suggest relying on OLS services. OLS will keep a registry in sync with prefixcommons and we can leverage this without, as @mbaudis recommended, having to maintain a specific registry.

(note: this would also help address #165)

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

No branches or pull requests

4 participants