Skip to content
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

Generate deprecate OWL class when converting merged terms #21

Open
GoogleCodeExporter opened this issue Mar 12, 2015 · 16 comments
Open

Comments

@GoogleCodeExporter
Copy link

See 
http://sourceforge.net/mailarchive/forum.php?thread_name=B2D79959-BB2E-4540-8AA2
-1DD753894813%40cam.ac.uk&forum_name=obi-devel for full thread.

Issue is when terms are merged, currently one ID "disappears" and is replaced 
by an alt_id on the term it is merged with. As a consequence, efforts relying 
on MIREOT to import selected terms can't retrieve them.

Proposal is to add a deprecated OWL class for the class that has been merged 
when converting to OWL. Note that this may not solve the issue for people using 
MIREOT in OBO - I believe Darren for PRO implemented such a tool; it may be 
worth coordinating.


Original issue reported on code.google.com by mcour...@gmail.com on 7 Apr 2011 at 4:46

@GoogleCodeExporter
Copy link
Author

can MIREOT not be changed?

in order to roundtrip it will be necessary to add additional metadata to the 
deprecated class. We'd need the relevant IAO properies for this

Original comment by cmung...@gmail.com on 7 Apr 2011 at 5:58

@GoogleCodeExporter
Copy link
Author

I cited MIREOT as this is the issue currently being dealt with, but other 
resources "lost" the term - see for example 
http://www.ebi.ac.uk/ontology-lookup/?termId=PATO:00001241

In my opinion having a deprecated term in OBO and OWL would make it easier to 
keep track of the term that was merged, especially if there are annotation 
properties to indicate correct replacement- maybe "replaced_by" would be 
suitable here? Maybe something we could add to a common deprecation policy?

IAO properties have been submitted to tracker (see 
http://code.google.com/p/information-artifact-ontology/issues/detail?id=90 and 
up) - as soon as they are updated with result of latest discussion we could add 
them into the file created at 
http://code.google.com/p/information-artifact-ontology/source/browse/trunk/src/o
ntology/obo2owlconversion.owl to support the conversion



Original comment by mcour...@gmail.com on 7 Apr 2011 at 6:13

@GoogleCodeExporter
Copy link
Author

so you're suggesting a change to how this is managed in obo-format too?

Original comment by cmung...@gmail.com on 7 Apr 2011 at 6:22

@GoogleCodeExporter
Copy link
Author

"so you're suggesting a change to how this is managed in obo-format too?"

Please no!  This would mean multiple databases, some with 100s of thousands of 
annotations to keep up to date, would have to change the way they track and 
manage ontology updates.

I suppose I could live with the OBI system in OWL and the mapping between the 
two systems being embedded in the conversion script. But, having a decent term 
merge system (one that maintains synonyms as well as deprecated IDs under the 
new term) is something I miss working in Protege. And as Chris says, can't 
MIREOT be modified to track alternate IDS?

Note - we actually officially have both systems in OBO. My understanding is 
that obsoletion and the addition of a replaced_by tag is used when some human 
oversight is needed. Merging of terms leading to an alt_id is used when it's 
safe for updating of IDs to occur automatically.

Original comment by dosu...@gmail.com on 5 May 2011 at 2:42

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

"Please no!  This would mean multiple databases, some with 100s of thousands of 
annotations to keep up to date, would have to change the way they track and 
manage ontology updates."

I agree, we would have to make a very compelling case for why this is being 
changed after 12 years, which would stall things considerably. If this isn't a 
requirement for Melanie we can focus on the OWL side of things and leave 
obo-format as is.

"Merging of terms leading to an alt_id is used when it's safe for updating of 
IDs to occur automatically"

It's commonly used when two terms are discovered to be equivalent. In principle 
we could leave both terms and add an equivalence axiom, but this is undesirable 
in obo format (and in fact impossible before obof1.4). 

Original comment by cmung...@gmail.com on 5 May 2011 at 4:22

@GoogleCodeExporter
Copy link
Author


I was suggesting to not delete the term in the OWL conversion, which is what 
happens when you replace a class definition by an alt_id annotation property. 

To address David's point, we could imagine keeping the alt_id property, and ask 
the script to do both: when merging PATO_0001237 with PATO_0001241, we would 
deprecate the former (adding an obsolescence reason "term merged" and a term 
replaced by annotation property pointing to PATO_0001241) and add its ID as an 
alt_id on the latter.
Is there a drawback doing so? 

Finally, if we can reach agreement, I would suggest to formally specify that 
behavior, so that tool developers (whether MIREOT or else) can build scripts 
based on a known specification.



Original comment by mcour...@gmail.com on 5 May 2011 at 4:23

@GoogleCodeExporter
Copy link
Author

I'm closing this now, as I believe we decided the current behavior was best

(I notice P4 now includes a "D" icon which is a start..)

Original comment by cmung...@gmail.com on 15 Jul 2011 at 8:29

  • Changed state: Done

@GoogleCodeExporter
Copy link
Author

Not an acceptable resolution. URIs may not disappear. That is a basic principle 
of the OBI deprecation policy and of what I understand the GO policy is. It may 
be that "not disappearing" means, in OBO, that it is marked as alt_id, but the 
OWL translation is that the URI is still present, marked as deprecated, axioms 
removed.

Original comment by alanruttenberg@gmail.com on 15 Jul 2011 at 8:36

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Apologies, you're quite right.

I mistakenly thought this was the request to generate an ObsoleteClass fake 
class under which to group the deprecated classes

Original comment by cmung...@gmail.com on 16 Jul 2011 at 2:48

@GoogleCodeExporter
Copy link
Author

This needs to be fixed soon in order for OBO ontologies to be safely edited in 
Protege.  For existing alt_ids, the translation needs to make an obsolete 
class. Unfortunately, I think this class will have to be anonymous (lacking a 
label), but I don't see any alternative.

Original comment by dosu...@gmail.com on 25 Jan 2012 at 12:02

@GoogleCodeExporter
Copy link
Author

Original comment by cmung...@gmail.com on 12 Sep 2013 at 4:23

  • Added labels: Priority-Critical
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

Same issue reported for HP on obo-admin/obo-foudnry-twg on Oct 30th 2014:

Hi,

My name is Justin Leong; I am a software developer working with Dr. Paul 
Pavlidis at the University of British Columbia on Phenocarta.

I noticed that the URL http://purl.obolibrary.org/obo/HP_0007053 for phenotype 
"Pontocerebellar hypoplasia" is no longer available. Would you happen to know 
what changed?

Thanks,

Justin

Original comment by mcour...@gmail.com on 31 Oct 2014 at 1:24

@GoogleCodeExporter
Copy link
Author

There was a proposed spec for how this would work ensuring roundtripping, 
thought it was in this tracker but can't find it.

No timeline for the fix so I recommend ontobee detects alt_ids and deals 
appropriately for now.

Original comment by cmung...@gmail.com on 5 Nov 2014 at 10:08

@GoogleCodeExporter
Copy link
Author

I am not sure the issue was ontobee related - rather a user was using the OWL 
file and not finding the classes he expects to (and he may already have data 
annotated with this ID)

Original comment by mcour...@gmail.com on 6 Nov 2014 at 12:51

@GoogleCodeExporter
Copy link
Author

owlcs/owlapi#317

Original comment by cmung...@gmail.com on 17 Nov 2014 at 11:33

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

No branches or pull requests

1 participant