[Obi-devel] Request for a range of ids for electrophysiology

[Alan Ruttenberg]

Yann Le Franc is starting some ontology work with collaborators around representing electrophysiology experiments. I've persuaded him it makes sense to work within OBI on this, suggesting that he do initial work by editing in a file that imports OBI. 

Can he be allocated a range of perhaps 5000 ids to allocate to his terms?

Thanks,

Alan

[Melanie Courtot]

Is there an OBI system to support ID ranges?

Melanie

> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr_______________________________________________
> Obi-devel mailing list
> Obi-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/obi-devel


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Obi-devel mailing list
Obi-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-devel

[Jie Zheng]

I think when we assigned IDs we can set starting number of IDs. Current
I am filling the OBI ids starting at 1000. Now it is close to 2000. I
remember before OBI worked by different branches and terms in each
branch assigned IDs in a specific range.

I found OBI:injection function with ID:OBI_0005246. So, 5000 ids might
not be good idea. No ids in 6000 range. I think he may use that range.

Jie

[Melanie Courtot]

Hi Jie,

When working with branches and ID range we actually had a protege plugin supporting that (and even so it was problematic)
I am worried that there is, at a minimum, no repository/file capturing which ID ranges have been allocated and to whom. My main concern with the whole ID range system is that there is no way to enforce it. But I won't reargue again; I think it is a poor decision which will led to errors and more pain fixing after the fact than actually allocating IDs to the few terms to move (if any at all) from the extension to the core.

To be clear in this case (we were just on a conference call with Yann) he is requesting 5000 IDs , i.e. from 10.000 to 15.000 for example, rather than the range 5000-6000.

Melanie

[Jie Zheng]

Hi Melanie,

Thanks for your clarification.

Agree with you that reserving a range of IDs is not a good strategy.
Current I am using the Java script I wrote to assign the IDs without
checking the range but check the available IDs greater than 1000. The
term with its original ID assigned by Protege and newly assigned OBI ID
was recorded and committed to OBI SVN after each assigning process. I
think it would be better to assign OBI IDs at one time.

eagle-i group has worked on device and function terms. They used what
IDs they want. When they finished, we merged it to obi.owl and then
assigned OBI ids. Don't know whether Yann would like to take this approach.

Chris and I began to use annotation 'source' to indicate where the terms
come from, such as ENCODE, NIAID GSCID-BRC, etc. If Yann would like to
track which terms come from his work, he may try the same approach.

Thanks,

Jie

[Carlo Torniai]

urigen can be a nice solution to explore.

https://code.google.com/p/urigen/

We are using in it for CTSaConnect and is pretty customizable.

Dr. Carlo Torniai

Assistant Professor
Ontology Development Group, OHSU Library

http://bit.ly/ctorniai

Department of Medical Informatics and Epidemiology
Oregon Health & Science University

tor...@ohsu.edu
skype: ctorniail

503-418-2499

[Jie Zheng]

I have tried the Urigen before. It would be nice if Urigen can provide a file which list all terms with old and newly assigned IDs.

Jie

[Melanie Courtot]

I talked a bit to Alan, and he mentioned he is willing to try and come up with a way to enforce ID ranges - my only concern with the ID range proposal is really the fact that at the moment there is no tool support.
I was happy with the strategy that others had followed earlier, such as IEDB, create terms in your file (importing OBI) and submit the file to OBI, and then assign IDs by script, but I am also willing to consider that it makes it easier to have stable IDs from the start. If there is a real way to prevent errors doing this, that works for me.

I agree that we will have to capture the attribution at the term level - are you using an IAO annotation, or is it an OBI one? It may be useful to have a short discussion and formalize this so that it is ready to use for all. "source" seems a bit short as a label, maybe "group source" or even "attribution" to be more explicit for example.

Good to hear that urigen worked well for you Carlo, we had tried and test it with Chris and ran into issues with group ids - maybe we should try again using individual details. Have you used it extensively? Any odd things, or all went well?

Cheers,
Melanie

[Jie Zheng]

Hi Melanie,

Chris and I think it would be nice to have an annotation to indicate
terms were added by request of which projects/community. Current we are
using "dc:source". It would be nice to have an IAO annotation for it.
However, IAO just have definition source now.

Jie

[Chris Mungall]

I think once you have the tool support figured out you'll be fine. GO has multiple humans one and agent writing to it every day, each have their own ID range. OboEdit only allocates IDs in the range. I think urigen should be a good replacement in the OWL world.

[James A. Overton]

I came across this old page about Quick ID on the OBI wiki:

http://obi-ontology.org/page/Quick_id

I haven't read the whole thing, but it seems that it was intended to solve the ID allocation problem we're discussing. Is there anyone on the list who could shed some light on it?

James

[Melanie Courtot]

Hi James,

I'm surprised Frank hasn't complained yet :)

As far as I remember, the quick ID proposal was in a nutshell to (1) educate users about the OBI hierarchy (2) allow them to add their terms in the right place and get an OBI ID immediately. Technically, it was proposed to have a obi-quick-id.owl file in which people could add terms and get an ID, with an "uncurated" status.

The proposal was aiming at decreasing the curation load on OBI developers (vs if you were to start from an SF submission) and allowing submitters to immediately get an ID for their term. The quick term proposal subsequently partly built upon those ideas.

Dirk and Frank left OBI shortly after, and the proposal was never truly implemented. It is quite old (as you can see the screenshots are P3 based for example). There were other difficulties - setting the ontology as active, lack of incentive to finish curation once the term had an ID etc.

It was not intended to assign IDs to a batch of terms, for that we would rather use the assign-id script Alan had developed (or I think Jie produced an updated version). We should probably obsolete that wiki page - or at least mark it as non implemented/inactive.

Melanie

[James A. Overton]

Hi everyone,

urigen looks like a good solution to me. "Self-serve" ID generation within Protege or via a website would be more convenient than running an ID assignment script.

The disadvantage is that we would have to keep a urigen server running and administered. Could we share this with your BBOP infrastructure, Chris? Or Carlo's infrastructure? Or share with other OBO projects? If we can't find another home, then I suspect that we could run the urigen server on Heroku at their free service level.

If people think that urigen is worth using, I'm willing to work on a solution. In any case, I will add ID assignment to the new OBI build tool I'm working on as soon as I have time.

James

[Melanie Courtot]

I think it would be a good solution; managing those manually is my main objection to using ID ranges. James and Simon had mentioned in the past that there may be ways they would provide a public server. I think Chris was also looking in setting up something for OBO.

Maybe check with them before spending time on the scripting?

Melanie

[Jie Zheng]

Hi James,

There is URIgen server running on EBI if I remember correctly. You need
to create an account and register your ontology. I have tested it
before. It works well for me. However, I didn't try to reserve ids
range. The reason that I didn't assign OBI IDs using it because I'd like
to get a list of terms with newly assigned IDs as a record. For OBI id
assignment, all related information has been committed under:
https://obi.svn.sourceforge.net/svnroot/obi/trunk/src/ontology/spreadsheets/new_ids
I think it is a good summary of what terms were added into OBI in a
period time and the type of new terms, (class, property, or instance, etc.)

The Java code for ID assignment is already under OBI svn/build. You have
moved them to old-build now. It was used to assign IDs during OBI
release process. I have also sent the request of features we need for
the release to Oort and Protege development group. I think you may
contact them if you want to spend time on writing release tool including
id assignment.

Thanks,

Jie

[James A. Overton]

Thanks Jie,

Ok. Having EBI host the urigen service for OBI sounds like a good option to me. I don't know Simon, but Melanie CC'd him on a previous email -- he might chime in, or maybe someone who knows him can ask directly.

If you can get all the OBI IDs you need on demand, whenever you want, then I don't see the need to reserve an ID range.

I agree that having a report of newly registered/used IDs is a good thing to include in the OBI release process. This might be a little harder to do if we use urigen, but it should still be possible. In any case, it won't be hard to move your AssignOBIIDs.java code into the new build tool -- I just haven't had time yet.

James

[Phillip Lord]

"James A. Overton" <ja...@overton.ca> writes:
> Ok. Having EBI host the urigen service for OBI sounds like a good option to
> me. I don't know Simon, but Melanie CC'd him on a previous email -- he might
> chime in, or maybe someone who knows him can ask directly.

Simon is a nice chap, and this is what urigen was intended for.

> If you can get all the OBI IDs you need on demand, whenever you want, then I
> don't see the need to reserve an ID range.

There isn't any point. It happens as you go.

>
> I agree that having a report of newly registered/used IDs is a good thing to
> include in the OBI release process. This might be a little harder to do if we
> use urigen, but it should still be possible. In any case, it won't be hard to
> move your AssignOBIIDs.java code into the new build tool -- I just haven't had
> time yet.

Another possible solution would be to add IDs into a different URI
namespace, which is noted to be temporary. UUIDs would work, for
instance. Then convert then to full IDs at release time. This would also
make obsolence easier, because you could have different obsolence
policies for the different namespaces.

Phil

[Melanie Courtot]

> [...]

>>
>> I agree that having a report of newly registered/used IDs is a good thing to
>> include in the OBI release process. This might be a little harder to do if we
>> use urigen, but it should still be possible. In any case, it won't be hard to
>> move your AssignOBIIDs.java code into the new build tool -- I just haven't had
>> time yet.
>
> Another possible solution would be to add IDs into a different URI
> namespace, which is noted to be temporary. UUIDs would work, for
> instance. Then convert then to full IDs at release time. This would also
> make obsolence easier, because you could have different obsolence
> policies for the different namespaces.

Another option may be to run Bubastis (the diff tool James wrote) between to to-be-released file and the last release?

I agree with Jie that I liked having the list for visual check when I was doing the releases.

Melanie

[jiez...@pcbi.upenn.edu]

Hi Melanie,

I used Bubastis to compare different release versions of OBI for
preparing release notes including a list of newly added classes. I got
some problem later. Perhaps after switch to BFO pre-graz (cannot
remember the details), Bubastis did not work well with OBI. Since
then, I wrote my own script to get the summary of new terms.

Jie

[Alan Ruttenberg]

I appreciate all the ideas, but I think I'd like to stick to the request I made. As a member of the OBI developers myself it wasn't so much asking for permission (as there is precedent for us doing this already) as asking for what the ids would be. Instead I'll have a look at what's in use and pick a range, adding IAO annotations to OBI that Chris created for this purpose. 

When there's a higher-tech solution in place I'll consider it. For now, having the range of ids will give Yann the autonomy he needs, without the pain of having temporary ids. I recommended his development proceed as I have done in the past - in a separate file that imports OBI. Protocol would be, as I practiced it in the past, to have him request review of that file when it is ready. As he would be joining the OBI community, the file will be kept in the OBI repository. When OBI reviews the terms we can decide to merge them into the main file permanently or not. Developers that are interested in working with the combined progress can import the file that Yann works with.

I greatly respect Melanie's and other's concerns in general, but find them misplaced in this case. The likelihood of a clash of ids is minimal, and the development in the distinct file will mean any such clash will be repairable. Since OBI devs won't see the additions until they are reviewed, unless they choose to, this manner of development should not cause mainstream OBO developers any problems even if there is a clash (the clash would be eventually resolved by giving a new id in the Yann project file). The determination of new ids would be simple, and would be done at review time. Those terms that are vetted and decided to be included into OBI would be the new terms, and be easily queried on the extra development file at that time.

I'll do the setup, once Yann confirms his group is interested in joining the OBI effort. I hope other members of the OBI consortium with an interest in electrophysiology will join in his effort, should they decide to go this route.

Best,

Alan

[Bjoern Peters]

Alan: We have a decision process [1], which says that for questions where there is no immediate consensus, we vote among active developers. Clearly there is no consensus on this. Also, while you are right that there is 'precedent' for assigning ID ranges, we stopped doing that and at present have no ID ranges reserved for anybody. Instead, we have either jointly edited terms, worked through QTT templates, or assigned OBI for a set of terms developed externally after group review. 

Finally, I would much rather communicate with Yan and hear what his needs and plans are rather than going through you. 

- Bjoern

[1] https://docs.google.com/document/d/1NWms5Zxo0BDWezIHO86Z4yh9qqjLCYdCgjwBzd2s-Xs/edit?disco=AAAAAEQJ1wY 

Looking at this it is apparent that we should lock the approved version from 2/27. There were apparently anonymous edits in it yesterday... We also need to act on the retirement of the no longer accurate wiki pages, and move over to the 'accepted votes page'. 

 

---

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1

_______________________________________________
Obi-devel mailing list
Obi-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-devel

--

Bjoern Peters
Assistant Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

[Simon Jupp]

Hi Melanie,
A public URIgen service hosted at the EBI is indeed on our todo list for the summer. In the meantime I'm happy to offer any help if you want to go down the URIgen route. It works nicely in our setting where multiple users and applications need to mint new URIs incrementally. To be honest we rarely give ids much thought anymore :). I should add that URIgen also allows you to assign and manage ranges for specific users, so the server will give the appropriate URI in sequence, depending on who is asking for it.

If you have any specific requirements not currently met by URIgen then please let me know.
Cheers
Simon

Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1

[Alan Ruttenberg]

Hi Simon,

I had a quick look at the docs but didn't understand everything about the operation and wondered if you could clarify.

1) There's mention of urigen not clashing with existing ids by having a pointer to the ontology, which I presume it reads. Is that the case? Does this mean that the ontology must be on the web to ensure that ids that don't clash? Or does it look at the ontology being edited as it exists in protege?

2) I don't see how the server is configured - did I miss the documentation? In particular, in a setup in which ids from one namespace are allocated to be unique across a ontology that is developed as multiple imports, can the policy be set so each of the designated imports take from the same pool?

3) Is urigen sensitive to what the active ontology in protege is? As I open different files, switch windows, change the active ontology, will the appropriate pool be automatically switched to, as necessary?

Thanks,

Alan

[Simon Jupp]

Hi Alan, 

1) There's mention of urigen not clashing with existing ids by having a pointer to the ontology, which I presume it reads. Is that the case? Does this mean that the ontology must be on the web to ensure that ids that don't clash? Or does it look at the ontology being edited as it exists in protege?

The urigen server does not currently check external ontologies for clashes. You can however preload a set of existing uris into the urigen database, which will get checked for clashes. The idea being once you start using urigen, you don't allow uri creation outside of urigen.

The Protege plugin will check that any new uris from urigen do not clash with the active ontology.

2) I don't see how the server is configured - did I miss the documentation? In particular, in a setup in which ids from one namespace are allocated to be unique across a ontology that is developed as multiple imports, can the policy be set so each of the designated imports take from the same pool?

urigen is currently configured to map one ontology uri to one uri creation strategy. Someone else already requested this feature to have shared configurations for multiple ontology URIs. In fact, they extended the urigen code here https://github.com/sessaid/com.essaid.p4.urigen.  I am going to incorporate this functionality into the next release. 

3) Is urigen sensitive to what the active ontology in protege is? As I open different files, switch windows, change the active ontology, will the appropriate pool be automatically switched to, as necessary?

Yes, this is correct. 

Cheers

Simon