search

information-artifact-ontology / ontology-metadata

OBO Metadata Ontology
Creative Commons Zero v1.0 Universal
19 stars 8 forks source link

Make a new IAO release #41

Closed cmungall closed 4 years ago

cmungall commented 5 years ago

http://purl.obolibrary.org/obo/IAO_8000006 still doesn't resolve (added in PR #36)

cmungall commented 5 years ago

@zhengj2007 can we have a new release?

zhengj2007 commented 5 years ago

@cmungall I will make the release and update the PURL, http://purl.obolibrary.org/obo/iao/ontology-metadata.owl. Since the term with IAO prefix, will the new term IRI resolvable?

cmungall commented 5 years ago

I will make the release and update the PURL, http://purl.obolibrary.org/obo/iao/ontology-metadata.owl.

Thanks. So I guess IAO isn't set up so this happens automatically?

Since the term with IAO prefix, will the new term IRI resolvable?

Hmm, are you saying that since iao.owl is not being released, ontobee, OLS, etc will not pick up the changes.

I think you are right. There are a number of possible solutions:

1 release the full IAO (and do this moving forward) 2 configure ontobee, OLS, etc such that they treat the separate artefact as it's own ontology (could be driven by metadata in the obo metadata file for iao) 3 make a separate entry (iaoom?) in the obo registry, and IAO formally hands over URIs in the OM subset to this new ontology 4 variant of above: create a new ontology for ontology metadata moving forward, re-mint these unused PURLs in this new space, and grandfather in existing in-used IAO OM PURLs

Thoughts on way forward?

We had some discussion at the RO meeting about PURLs from one ID space being handed over to other ontologies. I was of the position that this would cause unforeseen issues. In any case, OBO needs documentation about how to manage this kind of handoff, which AFAICT we lack. E.g. what happens with the PURL registry, where the central ledger of handovers is, what annotation properties do we use, etc.

I kind of wish OM had gone into it's own ontology to begin with, the use cases and usage patterns are radically different from the rest of IAO.

zhengj2007 commented 5 years ago

I am thinking about possible solution 3 since we have decided to make ontology metadata release independent from IAO. Regarding forward, can we depend on specific annotation like, rdfs:isDefinedBy, to resolve the Purl when it is set, otherwise, depend on prefix?

@cmungall Shall we bring it on next Tuesday's OBO operation committee meeting? Or do you think TG working group can make decision on it?

cmungall commented 5 years ago

I am thinking about possible solution 3 since we have decided to make ontology metadata release independent from IAO.

That makes sense

Regarding forward, can we depend on specific annotation like, rdfs:isDefinedBy, to resolve the Purl when it is set, otherwise, depend on prefix?

This seems reasonable. But I think the TWG needs to do some work to define procedures here.

Let's say ontology X wants to cede purl X1 to ontology Y (but X still needs to reference X1). X and Y can work together to make releases where both agree X1 rdfs:isDefinedBy Y. This in itself is a bit complicated, unless releases are synced there will be a period of conflict.

X will need to be very careful that it accidentally doesn't re-assign X1 to a new class within its own space. In their this should not happen if X1 is in an import. However, it's the kind of scenario that keeps me awake worrying at night. If something bad can happen with IDs, it will eventually.

We will also need to add specific redirect rules to the PURL server. These make me very nervous too, as they are not at the level of individual ontologies so there are many scenarios for things to go wrong. We discussed various strategies for the PURL redirects at the meeting, but James and I really want to keep the PURL server simple, lightweight, and maximally free of dependencies.

There is also the question of where the authoritative ledger for handovers lives (we can imagine scenarios where there is confusion about who the owner is, maybe even conflict). The PURL github may be one option here, but this seems like we are overloading dependencies. The PURL server is meant for one thing, redirecting PURLs on a per-ontology basis. I very much like separation of concerns.

This isn't to say none of this could work. But we have a bad history of underestimating the costs and complexity of things and stalling as a result.

I also think that we can evaluate the costs of obsoletions on a case by case basis, and in many cases the cost-benefit analysis will show that obsoleting a PURL and replacing it with a new one in the correct namespace will be the better option. Certainly for my PR #36, this is the case. On the other hand, the cost of obsoleting and reminding IAO_0000115 would be incredibly high.

For this reason I strongly advocate thinking deeply about modularity, use cases in advance of making an ontology, being very careful about minting out of scope URIs, and minimizing the need for handovers or obsoletion-replacements.

But we are where we are with IAO/OM. We could use this as a test case.

bpeters42 commented 5 years ago
zhengj2007 commented 5 years ago

@cmungall I understand your worries and concerns. Due to some IAO annotation properties have been widely used. It would be difficult to reassign the IRI.

I checked the IAO terms used in the ontology-metadata.owl. Here is the list of IAO terms in the ontology-metadata.owl: https://docs.google.com/spreadsheets/d/1bzaBrEakcj6fxUReEL4EDHNWsN5e1U27Dbjf3F6iqiM/edit?usp=sharing It contains 31 annotation properties, 18 individuals (mainly for specifying curation status and obsolescence reason), and 27 classes (few associated with ontology term annotation, such as, curation status specification, obsolescence reason specification). The IDs of the terms are not restricted to a specific range.

Shall we only maintain IAO annotation properties and ontology metadata related classes and individuals in IAO/OM and leave other terms still maintained by IAO?

If we decide to have different registry for ontology metadata with its own prefix, I think we may reassign IDs to those IAO ontology metadata terms that have not been used or widely used and use the OM prefix for newly added terms. In this way, it may minimize the issues you raised.

Any thoughts?

alanruttenberg commented 5 years ago

I have software that can generate a release. If James has time we could look at moving that process to robot. It generates both IAO merges as well as ontology metadata. The invocation that made the most recent release is in IAO's repo: make-release.lisp. That uses code from LSW (the above says which commit). Within LSW the code the file that does most of the work is release.lisp. There is documentation of what I am doing at the top of that file.

The reason the annotation properties were in IAO was because they are information, and IAO is about information. I'm fine with ontology metadata going under new management, but am against changing any identifiers.

jamesaoverton commented 5 years ago

I looked at this again. PR #42 is fine for making a release-able version of ontology-metadata.owl. Then IAO has to be updated. I'm happy to make IAO work with ROBOT.

@zhengj2007 Is this new ontology-metadata.owl from #42 just an update of the old src/ontology/ontology-metadata.owl in the main IAO repository?

If "yes" then we will just have to update src/ontology/iao-main.owl to point to this new file. Right?

zhengj2007 commented 5 years ago

I have made the ontology-metadata release (https://github.com/information-artifact-ontology/ontology-metadata/releases). Have not set the PURL yet. Will do it with IAO release.

@jamesaoverton Yes. You are right. We just need to update the iao-main.owl to point to this new file. It would be great if you can make IAO work with ROBOT. Thanks!

cmungall commented 5 years ago

@zhengj2007 any news on the release?

http://purl.obolibrary.org/obo/IAO_8000000

Still does not resolve, not visible in ontobee or OLS

zhengj2007 commented 5 years ago

@cmungall I have made the ontology-metadata OWL file ready for release. However, for making the IRI resolvable, it depends on the IAO release.

@jamesaoverton Any progress on IAO release? If not, is there anything I can help? Thanks!

jamesaoverton commented 5 years ago

Hi @zhengj2007. For the past six weeks I've been trying and failing to make time to work on an IAO release. I have too many other tasks that keep taking priority.

If you (or someone else) could take the lead on the release, I can help with the ontology metadata PURL stuff. That's the best suggestion that I can think of.

zhengj2007 commented 5 years ago

@jamesaoverton Thanks for the update. I am quite busy this week but will try to work on it next week.

cmungall commented 5 years ago

Hi @zhengj2007 any update on this?

I'm becoming increasingly convinced that we should make ontology metadata a completely standalone ontology with new URIs in its own ID space. I made #36 over a year ago

alanruttenberg commented 5 years ago

What exactly would that accomplish other than forcing people to change URIs?

If you want to maintain it separately, that's fine. It's already a separate file.

On Fri, Jun 7, 2019 at 5:45 PM Chris Mungall notifications@github.com wrote:

Hi @zhengj2007 https://github.com/zhengj2007 any update on this?

I'm becoming increasingly convinced that we should make ontology metadata a completely standalone ontology with new URIs in its own ID space. I made

36

https://github.com/information-artifact-ontology/ontology-metadata/pull/36 over a year ago

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/information-artifact-ontology/ontology-metadata/issues/41?email_source=notifications&email_token=AAB3CDURTGNYBI27VJ6B7QLPZLJG3A5CNFSM4F7LFOEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHCKKQ#issuecomment-500049194, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB3CDT4DS7KUGGCJD55HKDPZLJG3ANCNFSM4F7LFOEA .

cmungall commented 5 years ago

keep existing URIs but mint new ones in a separate ID space

proccaserra commented 5 years ago

@cmungall @jamesaoverton regarding issue #36 I can report the following problem reported by a collaborator (@mkoatwork) when accessing BioAssay Ontology from NCBO Bioportal (@graybeal) or EBI OLS (@simonjupp) (@EBISPOT)

Using BAO version 2.5 in NCBI Bioportal and EBi OLS (access both at 20.06.2019 10:00) gives a different representation: grafik

grafik

Based on @mkoatworkas report, I suspected that NCBO Bioportal (@graybeal) loaded the unreasoned version -> only asserted classes: (BAO pulled from github repo https://raw.githubusercontent.com/BioAssayOntology/BAO/master/bao_complete_merged.owl (because the following owl file http://www.bioassayontology.org/bao/bao_complete.owl served by OLS and Bioportal does not load in Protege)

image

Getting the inferred hierarchy (running hermit reasoner in Protege) shows the following:

image

Pay attention to the Protege view Inferred / Asserted toggle box.

OLS is loading the complete-merge & reasoned version of BAO NCBO seems to have loaded the asserted version.

this would be my explanation to the difference you observed.

If my conclusions are correct about the difference being observed between NCBO & OLS, an ontology metadata detailing whether an ontology is saved as asserted or inferred would help services such as NCBO and OLS (as well as users). @jamesaoverton would be nice to have that metadata tag added automatically when invoking Robot reason / merge commands. @cmungall looking at issue #36, how should module be understood ? is a term such as 'IAO:8000013 ! reasoned ontology subset module' meant to annotate a whole reasoned artefact too or should a new term be added?

jamesaoverton commented 5 years ago

@proccaserra We have longstanding plans for ROBOT to add metadata about processing steps: https://github.com/ontodev/robot/issues/6. #36 was supposed to be a start, but we got stalled with the IAO release process.

The question has always been how much or how little information to include, and how to define it. Just saying "asserted" or "inferred" is highly ambiguous. Even in the example you provided, you could have as little information as "we ran a reasoner", and as much as: the details of the input file, the ROBOT version, the name and version of the reasoner, the reasoner settings such as which axioms to infer, etc. I'd prefer to discuss that on the ROBOT tracker.

(I'm not sure how any of the previous discussion applies to BAO, which is not an OBO ontology, does not use our PURL system, only uses a couple of IAO properties, and I guess does not follow our convention of official releases being reasoned. I don't know if they use ROBOT, either. But the point stands that we often want to know more about the artifacts we're using.)