Remove is_a from ro-chado.obo

[abretaud]

As discussed in galaxy-genome-annotation/docker-tripal#6, we have a problem loading ro-chado.obo in chado.
It looks like removing "OBO_REL:is_a" from ro-chado fixes the problem.

[cmungall]

@cybersiddhu @kimrutherford comments? The fake is-a relation was added specifically to support chado, as discussed in #68

[kimrutherford]

@cybersiddhu @kimrutherford comments?

It won't be a problem for us. We'll load is_a separately if needed.

[scottcain]

I find it hard to believe that is_a is actually causing the problem @abretaud is describing. I'll discuss over on their tripal tracker.

[cybersiddhu]

Yes, the is_a was a problem, as mentioned here, i have to use my custom fork to chop it out.
The reason was that the perl obo parser supplies its own is_a during parsing of any obo file, which conflicts with this explicit is_a in the ro file.

[cmungall]

OK, we should move forward. The fix needs to be in the perl script though rather than derived file, see #119

[abretaud]

Do you mean #119 fixed the problem or not? This can be closed if it's the case
Anyway, I'm working on a workaround in the script that loads obo into chado

[cmungall]

I merged it, but also did #121 to ensure future releases don't include the fake isa

[abretaud]

Great, thank you!

[abretaud]

Hum, the fake is_a was reintroduced in this commit: fc42248
Was it intended or not?

[cmungall]

Yes it was intended. In fact ro-chado was originally created to provide
this for some users, see for example
#68 (comment)

But those who need the fake stanza can add it separately, at it seems
the majority want this excluded.

On 29 Aug 2016, at 6:32, Anthony Bretaudeau wrote:

Hum, the fake is_a was reintroduced in this commit:
fc42248
Was it intended or not?

You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
#115 (comment)

[abretaud]

Ok, that's what I understood too, but the fake stanza is back in the latest revision

[cmungall]

Oh, sorry I misunderstood. You are quite right. The last release contained an older version of ro-chado. The release Makefile now ensures that this is made as in sync with each release. I'll make a new release shortly

[abretaud]

Hum, are you still thinking about the new release? (No hurry at all, just in case you forgot about it)

[cmungall]

Permanent URL for this release: http://purl.obolibrary.org/obo/ro/releases/2016-09-02/subsets/ro-chado.obo

PURL for latest:
http://purl.obolibrary.org/obo/ro/subsets/ro-chado.obo

[abretaud]

Awesome, thank you !
I just saw that there is now a subsetdef: RO:0002259 "" after the "subsetdef: ro-eco "" at the beginning, is it normal? I guess it has low impact, just wondering

[cmungall]

It looks like the name of the slim/subset is not being persisted in the
conversion from owl. This is an issue with the OWLAPI OWL->OBO (which I
wrote..). It should be fixed, but in the interim this only affects you
if you care about the RO subsets, and you want to be sure they have
meaningful names. I don't think this is even included in a typical chado
load.

On 2 Sep 2016, at 13:11, Anthony Bretaudeau wrote:

Awesome, thank you !
I just saw that there is now a subsetdef: RO:0002259 "" after the
"subsetdef: ro-eco "" at the beginning, is it normal? I guess it has
low impact, just wondering

You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
#115 (comment)

[abretaud]

Ok, yes, I think it should be ok like that
Thank you very much for your help!