Second colon in term id causes AmiGO to not display correctly

[planteome]

Second colon in term id causes AmiGO to not display correctly

[marieALaporte]

This is not specific to Cassava.

For all the categorical scales, the different categories are in the format CO_334:XXXXXXX:X, where CO_334:XXXXXXX:1 is the first category, CO_334:XXXXXXX:2 is the second category, etc., of the scale CO_334:XXXXXXX.

According to the OBO spec (1.2), there's no restriction regarding the structure of the IDs. Only the version 1.4 of the spec (which is still a draft) mentions that a valid ID must contain only 1 colon.

I am ok to change the extra colon by something else only if it works too for @nmenda.

What character would be convenient for AmiGO2?

[cmungall]

On 12 Feb 2016, at 5:25, Marie-Angélique wrote:

This is not specific to Cassava.

For all the categorical scales, the different categories are in the
format CO_334:XXXXXXX:X, where CO_334:XXXXXXX:1 is the first category,
CO_334:XXXXXXX:2 is the second category, etc., of the scale
CO_334:XXXXXXX.

According to the OBO spec (1.2), there's no restriction regarding the
structure of the IDs. Only the version 1.4 of the spec (which is still
a draft) mentions that a valid ID must contain only 1 colon.

The 1.4. spec is far more reliable than the 1.2 spec (which is in fact
not a spec, but a guide).

All IDs should be valid CURIEs, so one : only

I am ok to change the extra colon by something else only if it works
too for @nmenda.

If @nmenda is using chado then I believe the extra : is also problematic

What character would be convenient for AmiGO2?

This is more of an issue for obo/owl conversion. The underscore in the
prefix will cause issues with something like CO_334:11111-2 (try a
roundtrip)

This is unfortunate. How would you feel about rolling all COs into a
single prefix?

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[elserj]

Apparently the second colon was changed to a "-" (dash), but the problem persists. My guess is that no characters besides numeric is allowed after the colon (maybe letters?)

My guess is that it is wrong to try to have "sub-term ids" in any way like this. Probably better to just have unique numbers even though the terms are related in this way.

[cmungall]

OK, this is unexpected behavior. It's actually caused by a combination of two things:

1. Underscore in prefix
2. Dash in local ID

Technically it's conformant with the rather abstruse grammar here: http://owlcollab.github.io/oboformat/doc/obo-syntax.html#2.5

But the OWLAPI OBO converter doesn't like this. So it ends up not contracting the URI, the URI is used directly as the CURIE

I'm afraid we won't be pushing a fix to the OWLAPI for this one (if we did it would take a while to percolate)

Removing one of the conditions above should be sufficient. I would strongly prefer ID prefixes not to include underscores, this creates ambiguities when going from purl to CURIE.

Can we do CO334:0100542-1?

That would work technically.

But there is still a wider issue here. All prefixes should go in a central registry. To facilitate coordination, I would recommend:

• CO registers a single prefix in OBO. I would make this unambiguous, ie longer than CO. Maybe SCO for species crop ontology
• CURIEs use this single prefix and stratify by species within it. E.g. SCO:334-0100542-1

[cooperl09]

Currently loading a test file (CO cassava traits) on planteome-dev in which the colon in the prefix has been removed, as in Chris' suggestion, to see if it displays better with the hyphens at the end.
@marieALaporte

[marieALaporte]

I am ok with a quick fix for now. I can help with that if needed. Anyway, we currently have two versions of each obo file: one for our partners to use and one dedicated to AmiGO.

But we need to discuss the issue further before any strong move. We need to keep in mind that the CO ontologies are actually used to annotate data in the different CGIAR centers. The CO "name/brand" is well known in the agricultural domain. I can be convinced to make a change that will make CO more compliant with the obo foundry, but not if the reason is only technical. Of course, this change will have to be as transparent as it can for our users.

@cmungall why the CO IDs are not a problem in Protégé? Indeed, Protégé does not complain although it uses OWL API.

[marieALaporte]

We decided last year to remove the CassavaScale terms that are categories from the file that is used by AmiGO, so I am closing this issue for now