Open GoogleCodeExporter opened 9 years ago
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
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
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
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
[deleted comment]
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
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
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
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
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
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
Original issue reported on code.google.com by
alanruttenberg@gmail.com
on 17 Dec 2014 at 5:01