[Obi-devel] attribution of terms

[Melanie Courtot]

[starting a new thread for that discussion - copying discussion below for reference]


Hi Jie,

What I had in mind (and that we discussed briefly with Yann too) was the need for his terms to be attributed to his work. So let's say his group is called "X", he would create an curate terms and submit them for inclusion to OBI. However we would like to be able to identify group X as the one who created and should be credited with the term. For IEDB, we used term editor, but I don't know if this is enough - it seems to indicate more the task of entering the term than the process of curating it etc.

I am not sure about your usage of dc:source; is it to identify community who request the term. For example I say "I need a term for assay Z", you add it for me, you put a dc:source "AE ontology"? Or would it be rather the case in which I create a term in AERO, realize that it is better suited for OBI and submit it there, then you would add a dc:source "AE ontology"?

Thanks,
Melanie


On 2013-04-25, at 3:00 PM, Jie Zheng wrote:

> 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
>
>
> On 4/25/2013 5:51 PM, Melanie Courtot wrote:
>> 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
>>
>>
>> On 2013-04-25, at 2:01 PM, Jie Zheng wrote:
>>
>>> 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
>>>
>>> On 4/25/2013 4:58 PM, Carlo Torniai wrote:
>>>> 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
>>>>
>>>>
>>>>
>>>> On Apr 25, 2013, at 1:51 PM, Jie Zheng <jiez...@pcbi.upenn.edu> wrote:
>>>>
>>>>> 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
>>>>>
>>>>> On 4/25/2013 4:42 PM, Melanie Courtot wrote:
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> On 2013-04-25, at 1:35 PM, Jie Zheng wrote:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> On 4/25/2013 4:27 PM, Melanie Courtot wrote:
>>>>>>>> Is there an OBI system to support ID ranges?
>>>>>>>>
>>>>>>>> Melanie
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2013-04-25, at 1:24 PM, Alan Ruttenberg wrote:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> 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
>









------------------------------------------------------------------------------
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]

Hi Melanie,

I think term editor is not enough. Lately Chris and I added some terms
requested by two groups, NIAID GSCID-BRC metadata project and ENCODE
project. Both of us are term editors since we participated in
preparation of both textual and logical definitions. Of course, the
people in these two groups provided us documents allow us to work on the
terms. I am not the person belong to either of these groups. I am not
sure if I used ENCODE group or NIAID GSCID-BRC group is good enough if
the terms need to be clarified or modified. For IEDB terms, it is
different story. The group is involved in OBI development and we know
who we can talk to. So, we decided to use dc:source. I think another
benefit is if we indicate where the terms come from it would be easy to
find out how many communities/projects contribute to OBI.

I do think about to use dc:source to indicate the term come from which
external ontology too. I have added some MO and EFO terms in OBI. I used
definition source to provide the term's external EFO id or MO id. For
EFO terms, I copied over both term editor and logical axioms, too. I
think it would be better to use another annotation rather than
definition source because it specifies the source of textual definition
if I understand correctly.

I am not sure about the usage of dc:source either. The comment of
dc:source is "A reference to a resource from which the present resource
is derived." So, I am not against to add an IAO annotation. We decided
to choose an existing one because the slow development of IAO. I do want
to discuss it in OBI but have not found chance yet. There are too many
issues need to be discussed in OBI dev call. If IAO makes the annotation
available, I would like to replace dc:source by it.

Thanks,

Jie

[Melanie Courtot]

Hi Jie,

Thanks for the explanation. I am not sure I understand fully why we need to point out which community requested the term - if I understood what you said, the ENCODE project needed a term and made a request to add it, and then Chris and you worked on it and added it into OBI. It seems that you and Chris are the person who should be credited with the term? In my case in the past we had people from other projects contributing terms to OBI, for example for flow cytometry - if they were the ones creating the term (i.e., label, definition) they are the term editor in the file (if I entered the term myself I may have added my name, though I think I usually didn't as I just did the "physical" work)

I didn't follow the MO and EFO terms - shouldn't they just be mireoted in?

Maybe it would be useful to have a short call with interested people and sort the various cases out based on usage, and then figure out what is similar/different and if we need to create new properties.

I created a doodle poll at http://www.doodle.com/25b47m8qqpbvadi7 - all: indicate your availability if you want to discuss this.

Cheers,
Melanie

[Jie Zheng]

Hi Melanie,

Please see my comments inline.

On 4/25/2013 7:28 PM, Melanie Courtot wrote:
> Hi Jie,
>

> Thanks for the explanation. I am not sure I understand fully why we need to point out which community requested the term - if I understood what you said, the ENCODE project needed a term and made a request to add it, and then Chris and you worked on it and added it into OBI. It seems that you and Chris are the person who should be credited with the term? In my case in the past we had people from other projects contributing terms to OBI, for example for flow cytometry - if they were the ones creating the term (i.e., label, definition) they are the term editor in the file (if I entered the term myself I may have added my name, though I think I usually didn't as I just did the "physical" work)

For ENCODE project, Chris and I created template based on OBI assay
design pattern. And then we reviewed the terms they submitted and added
logical axioms based on the OBI pattern. Besides, name of ENCODE person
who worked on the terms were listed as term editors as well.

>
> I didn't follow the MO and EFO terms - shouldn't they just be mireoted in?

MO did not use BFO as upper ontology. The terms were integrated into OBI
which should not use mireot strategy. EFO is an application ontology. I
added EFO assay terms which should are in OBI scope. EFO added the terms
since they are not available in OBI. We have discussed with James. He
would like the terms in OBI too. And EFO id does not fall in OBO Foundry
ID format.

>
> Maybe it would be useful to have a short call with interested people and sort the various cases out based on usage, and then figure out what is similar/different and if we need to create new properties.

Sure.

> I created a doodle poll at http://www.doodle.com/25b47m8qqpbvadi7 - all: indicate your availability if you want to discuss this.

Will do it. Thanks,
> Cheers,
> Melanie
Jie

[Melanie Courtot]

On 2013-04-25, at 4:38 PM, Jie Zheng wrote:

> Hi Melanie,
>

> Please see my comments inline.
>
> On 4/25/2013 7:28 PM, Melanie Courtot wrote:
>> Hi Jie,
>>
>> Thanks for the explanation. I am not sure I understand fully why we need to point out which community requested the term - if I understood what you said, the ENCODE project needed a term and made a request to add it, and then Chris and you worked on it and added it into OBI. It seems that you and Chris are the person who should be credited with the term? In my case in the past we had people from other projects contributing terms to OBI, for example for flow cytometry - if they were the ones creating the term (i.e., label, definition) they are the term editor in the file (if I entered the term myself I may have added my name, though I think I usually didn't as I just did the "physical" work)
> For ENCODE project, Chris and I created template based on OBI assay design pattern. And then we reviewed the terms they submitted and added logical axioms based on the OBI pattern. Besides, name of ENCODE person who worked on the terms were listed as term editors as well.

so the dc:source is really to indicate the group which originally requested the term, and contributed to its curation?

>>
>> I didn't follow the MO and EFO terms - shouldn't they just be mireoted in?
> MO did not use BFO as upper ontology. The terms were integrated into OBI which should not use mireot strategy.

Still not sure I understand that. NCBI Taxon or CARO were not build under BFO, but we mireoted them nonetheless. Actually in the case of CARO we specifically didn't like their upper level hierarchy (I think it has changed since however)

> EFO is an application ontology. I added EFO assay terms which should are in OBI scope. EFO added the terms since they are not available in OBI. We have discussed with James. He would like the terms in OBI too. And EFO id does not fall in OBO Foundry ID format.

I feel like I am missing something, sorry... For mireot, it doesn't really matter whether you are an application or reference ontology. So if EFO has term X that OBI wants to use, we could just import this one. Having an OBO foundry ID compliant URI or not shouldn't matter either.

>>
>> Maybe it would be useful to have a short call with interested people and sort the various cases out based on usage, and then figure out what is similar/different and if we need to create new properties.
> Sure.

Maybe we could touch on the above as well, probably easier by voice than by email.

>> I created a doodle poll at http://www.doodle.com/25b47m8qqpbvadi7 - all: indicate your availability if you want to discuss this.
> Will do it. Thanks,

Thanks!

Melanie

[Jie Zheng]

On 4/26/2013 12:54 PM, Melanie Courtot wrote:
> On 2013-04-25, at 4:38 PM, Jie Zheng wrote:
>
>> Hi Melanie,
>>
>> Please see my comments inline.
>>
>> On 4/25/2013 7:28 PM, Melanie Courtot wrote:
>>> Hi Jie,
>>>
>>> Thanks for the explanation. I am not sure I understand fully why we need to point out which community requested the term - if I understood what you said, the ENCODE project needed a term and made a request to add it, and then Chris and you worked on it and added it into OBI. It seems that you and Chris are the person who should be credited with the term? In my case in the past we had people from other projects contributing terms to OBI, for example for flow cytometry - if they were the ones creating the term (i.e., label, definition) they are the term editor in the file (if I entered the term myself I may have added my name, though I think I usually didn't as I just did the "physical" work)
>> For ENCODE project, Chris and I created template based on OBI assay design pattern. And then we reviewed the terms they submitted and added logical axioms based on the OBI pattern. Besides, name of ENCODE person who worked on the terms were listed as term editors as well.
> so the dc:source is really to indicate the group which originally requested the term, and contributed to its curation?

Yes.

>
>>> I didn't follow the MO and EFO terms - shouldn't they just be mireoted in?
>> MO did not use BFO as upper ontology. The terms were integrated into OBI which should not use mireot strategy.
> Still not sure I understand that. NCBI Taxon or CARO were not build under BFO, but we mireoted them nonetheless. Actually in the case of CARO we specifically didn't like their upper level hierarchy (I think it has changed since however)

MO is completely different story. If you check why we proposed to
develop OBI, you can find it initiated from development of FuGO
ontology. Integration of MO to FuGO and alignment of MO to BFO is part
of development of OBI. That's what Chris and I worked on for about two
years. It's my fault that I haven't finished up writing and make the
work be published.

>
>> EFO is an application ontology. I added EFO assay terms which should are in OBI scope. EFO added the terms since they are not available in OBI. We have discussed with James. He would like the terms in OBI too. And EFO id does not fall in OBO Foundry ID format.
> I feel like I am missing something, sorry... For mireot, it doesn't really matter whether you are an application or reference ontology. So if EFO has term X that OBI wants to use, we could just import this one. Having an OBO foundry ID compliant URI or not shouldn't matter either.

I think it is important to keep assay terms in OBO Foundry reference
ontology, OBI. I have submitted a paper to ICBO which shows why it is
important.

>>> Maybe it would be useful to have a short call with interested people and sort the various cases out based on usage, and then figure out what is similar/different and if we need to create new properties.
>> Sure.
> Maybe we could touch on the above as well, probably easier by voice than by email.

Sure.

[Melanie Courtot]

On 2013-04-26, at 10:27 AM, Jie Zheng wrote:

> On 4/26/2013 12:54 PM, Melanie Courtot wrote:
>> On 2013-04-25, at 4:38 PM, Jie Zheng wrote:
>>
>>> Hi Melanie,
>>>
>>> Please see my comments inline.
>>>
>>> On 4/25/2013 7:28 PM, Melanie Courtot wrote:
>>>> Hi Jie,
>>>>
>>>> Thanks for the explanation. I am not sure I understand fully why we need to point out which community requested the term - if I understood what you said, the ENCODE project needed a term and made a request to add it, and then Chris and you worked on it and added it into OBI. It seems that you and Chris are the person who should be credited with the term? In my case in the past we had people from other projects contributing terms to OBI, for example for flow cytometry - if they were the ones creating the term (i.e., label, definition) they are the term editor in the file (if I entered the term myself I may have added my name, though I think I usually didn't as I just did the "physical" work)
>>> For ENCODE project, Chris and I created template based on OBI assay design pattern. And then we reviewed the terms they submitted and added logical axioms based on the OBI pattern. Besides, name of ENCODE person who worked on the terms were listed as term editors as well.
>> so the dc:source is really to indicate the group which originally requested the term, and contributed to its curation?
> Yes.
>>
>>>> I didn't follow the MO and EFO terms - shouldn't they just be mireoted in?
>>> MO did not use BFO as upper ontology. The terms were integrated into OBI which should not use mireot strategy.
>> Still not sure I understand that. NCBI Taxon or CARO were not build under BFO, but we mireoted them nonetheless. Actually in the case of CARO we specifically didn't like their upper level hierarchy (I think it has changed since however)
> MO is completely different story. If you check why we proposed to develop OBI, you can find it initiated from development of FuGO ontology. Integration of MO to FuGO and alignment of MO to BFO is part of development of OBI. That's what Chris and I worked on for about two years. It's my fault that I haven't finished up writing and make the work be published.

Sorry my mistake - I didn't make the link MO = MGED.
For past MO terms under instruments we had decided on using definition source, see for example http://purl.obolibrary.org/obo/OBI_0400105. Same was done with IEDB terms. Certainly worth homogenizing.

>>
>>> EFO is an application ontology. I added EFO assay terms which should are in OBI scope. EFO added the terms since they are not available in OBI. We have discussed with James. He would like the terms in OBI too. And EFO id does not fall in OBO Foundry ID format.
>> I feel like I am missing something, sorry... For mireot, it doesn't really matter whether you are an application or reference ontology. So if EFO has term X that OBI wants to use, we could just import this one. Having an OBO foundry ID compliant URI or not shouldn't matter either.
> I think it is important to keep assay terms in OBO Foundry reference ontology, OBI. I have submitted a paper to ICBO which shows why it is important.

Being part of OBI and having an OBI URI are 2 different things. Note that I am not arguing that those terms shouldn't be in OBI, with an OBI style URI, I am just trying to understand the usage case in which we need to create an OBI ID for a pre existing term and what type of information is embedded in dc:source.

Based on the above, it seems we have at least 3 cases:
- referencing a project that contributed to the term creation and curation (e.g. ENCODE case)
- attributing term to a pre existing project which merged with OBI (e.g. MO case, IEDB case)
- mapping to a term that co-exists (EFO case - though EFO will change the ID to OBI)

I can also think of the case of pointing at a term, what is called xrefs in oboinowl - a term in another resource which despite not being identical can provide information about the meaning of the current term. For my project I also need to have an annotation "maps_to" which indicates a correspondence between terms that are not equals but are related and can be interchanged computationally for processing (e.g., Brighton:rash and MedDRA:rash)

Does that seem accurate?

[Jie Zheng]

Hi Melanie,

Thanks for nice summary.

I'd like to have "maps_to" annotation too.

Jie

On 4/26/2013 1:45 PM, Melanie Courtot wrote:
> Based on the above, it seems we have at least 3 cases:
> - referencing a project that contributed to the term creation and curation (e.g. ENCODE case)
> - attributing term to a pre existing project which merged with OBI (e.g. MO case, IEDB case)
> - mapping to a term that co-exists (EFO case - though EFO will change the ID to OBI)
>
> I can also think of the case of pointing at a term, what is called xrefs in oboinowl - a term in another resource which despite not being identical can provide information about the meaning of the current term. For my project I also need to have an annotation "maps_to" which indicates a correspondence between terms that are not equals but are related and can be interchanged computationally for processing (e.g., Brighton:rash and MedDRA:rash)
>
> Does that seem accurate?