Add IDO_STAPH to OBO Foundry page listing of ontologies, and to Ontobee

[GoogleCodeExporter]

According to Albert there was an attempt at doing this last year, but it spun 
off into a critique of how the extension strategy would map to ID spaces. 
Specifically if IDO generated a large modular lattice of infectious diseases 
based on host type and infectious agent type, that would generate too many 
prefixes / ID spaces. IDO agreed to have IDO-STAPH URIs use the same prefix as 
IDO with reserved block of ids in the same space: 
http://purl.obolibrary.org/obo/IDO_02NNNNN 

Currently IDO Brucellosis has block http://purl.obolibrary.org/obo/IDO_01NNNNN
and IDO Tuberculosis (in very early development) has block 
http://purl.obolibrary.org/obo/IDO_03NNNNN  

However, it isn't clear why it isn't listed on the OBO Foundry Library page.

Original issue reported on code.google.com by alanruttenberg@gmail.com on 17 Dec 2014 at 5:01

[GoogleCodeExporter]

The obofoundry table lists those prefixes which have been registered with the 
OBO Foundry as per the OBO ID policy at 
http://www.obofoundry.org/id-policy.shtml In this case, the registered prefix 
is IDO, which is listed.

Original comment by mcour...@gmail.com on 17 Dec 2014 at 6:29

[GoogleCodeExporter]

That doesn't work if independent efforts share an ID space. It should 
correspond to the ontology development efforts. A request for review of 
IDO_STAPH is not a request for review of IDO.

Such a policy goes against our goals of de-emphasizing the ontology prefix.

Original comment by alanruttenberg@gmail.com on 17 Dec 2014 at 6:34

[GoogleCodeExporter]

Maybe submit a new tracker asking for a modification of the ID policy?

Original comment by mcour...@gmail.com on 17 Dec 2014 at 6:56

[GoogleCodeExporter]

Hmm. I'm not seeing a restriction to that effect, or that this document speaks 
at all to what goes on the OBO Foundry page or Ontobee.

Could you point out the part of the document on which you base your conclusion? 

Original comment by alanruttenberg@gmail.com on 18 Dec 2014 at 9:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

By my read this speaks to the acceptable form for a URI. STAPH_IDO ids conform 
It doesn't say two ontologies can't share an idspace or that the OBO Foundry 
Web page only lists IDSpaces. This request is not for a new ID space - rather 
for another listing on the OBO Foundry page.

Original comment by alanruttenberg@gmail.com on 18 Dec 2014 at 9:45

[GoogleCodeExporter]

Demo of how this might work in the new system here:

http://enigmatic-wildwood-5530.herokuapp.com/

See d-acts

No idea if this will work at all with existing perl legacy

Original comment by cmung...@gmail.com on 18 Dec 2014 at 10:05

[GoogleCodeExporter]

In the URI http://purl.obolibrary.org/obo/IDO_02NNNNN , the IDSPACE is IDO.
In the URI http://purl.obolibrary.org/obo/IDO_STAPH_02NNNNN , the IDSPACE is 
IDO_STAPH. 

The form of URIs dictates which is the IDSPACE, which (as Chris points out) in 
turns dictates what is displayed on the current OBO Foundry page. Hope this 
helps.

Original comment by mcour...@gmail.com on 18 Dec 2014 at 10:28

[GoogleCodeExporter]

Not everything that is current is correct. It is *we* who should dictate what 
the page says. Chris shows one way this could be accomplished.

I would suggest it be presented slightly differently, in the interest of making 
sure that ontology projects don't land up feeling like they are second class 
citizens.

The suggestion would be to have two columns

Ontology project / Ontology IDSPACE

Not sure if project is the right word - we could work on that. Then note 
somewhere that the IDSPACE is the mnemonic unless otherwise specified and then 
only fill the column when it is.

Then the display would look like:

IAO       
D-ACTS  IAO
RS

We have discussed that a more flexible and transparent way to associate a term 
with the project that manages it is by using rdfs:isDefinedBy, so we no longer 
need to maintain (and in fact would like to de-emphasize so as to make change 
of term management less of a cognitive dissonance) the IDSPACE = managing 
project assumption.

Here'a another idea, maybe better.

Have the *first* column be the ontology name. Have the *second* column be the 
IDSPACE the project uses. Drive the display of the page by the ontology name 
not the IDSPACE.

Original comment by alanruttenberg@gmail.com on 19 Dec 2014 at 5:51

[GoogleCodeExporter]

Maybe even better - don't even bother to put the IDSPACE on the front page. 
Link the ontology name to the PURL and have the detail page show the default 
IDSPACE as a detail. If wanted (though it would be redundant) include the path 
below /obo where the default version of the ontology is. 

If we need to add clarification or modify the ID policy document let's do that.

Onwards and forwards and all that.

Original comment by alanruttenberg@gmail.com on 19 Dec 2014 at 5:54

[GoogleCodeExporter]

If modifications of the ID policy are needed we have an established process to 
do that.

Original comment by mcour...@gmail.com on 19 Dec 2014 at 4:14

[alanruttenberg]

Also IDOBRU https://sourceforge.net/p/idobru/code/HEAD/tree/trunk/src/ontology/brucellosis_merged.owl

[cmungall]

Assume this is no longer required. Add to main tracker if required.