[Obi-devel] annotation properties for attribution of terms

[Melanie Courtot]

Hi all,

Following the discussion at http://sourceforge.net/mailarchive/forum.php?thread_name=517AD020.1020505%40pcbi.upenn.edu&forum_name=obi-devel, Jie and I will have a call tomorrow 10am PST, 1 pm EST to try addressing attributions of terms and create needed annotation properties.

Use 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)
- 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.
- 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)

All are welcome to attend - please let me know so I can add you to the skype call.

Cheers,
Melanie
------------------------------------------------------------------------------
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

[Christian Bölling]

See inline.

- Christian

2013/5/2 Melanie Courtot <mcou...@gmail.com>

Hi all,

Following the discussion at http://sourceforge.net/mailarchive/forum.php?thread_name=517AD020.1020505%40pcbi.upenn.edu&forum_name=obi-devel, Jie and I will have a call tomorrow 10am PST, 1 pm EST to try addressing attributions of terms and create needed annotation properties.

Use 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)

 

Could owl:equivalentClass and owl:equivalentProperty be used? If not, how is this different?

- 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.
- 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)

If they can be interchanged computationally the are owl:equivalentClass -es, or what is intended here? Could the established skos properties (skos:exactMatch, skos:narrowMatch, skos:broadMatch, skos:related and possibly others) be used?

 

All are welcome to attend - please let me know so I can add you to the skype call.

Cheers,
Melanie

--
--
informatio...@googlegroups.com
To change settings, visit
http://groups.google.com/group/information-ontology

---
You received this message because you are subscribed to the Google Groups "information-ontology" group.
To unsubscribe from this group and stop receiving emails from it, send an email to information-onto...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Melanie Courtot]

Thanks Christian,

On 2013-05-02, at 11:53 AM, Christian Bölling wrote:

> See inline.
>
> - Christian
>
>
> 2013/5/2 Melanie Courtot <mcou...@gmail.com>
> Hi all,
>
> Following the discussion at http://sourceforge.net/mailarchive/forum.php?thread_name=517AD020.1020505%40pcbi.upenn.edu&forum_name=obi-devel, Jie and I will have a call tomorrow 10am PST, 1 pm EST to try addressing attributions of terms and create needed annotation properties.
>
> Use 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)
>
> Could owl:equivalentClass and owl:equivalentProperty be used? If not, how is this different?

The EFO case was raised by Jie and is not very clear to me either, I hope we can discuss on the call and see how (and if) it is different. I was expecting to just mireot in the EFO term for example. It was hard to discuss all cases by email and sometimes confusing, so we thought it would be easier to do that via voice.

>
> - 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.
> - 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)
>
> If they can be interchanged computationally the are owl:equivalentClass -es, or what is intended here? Could the established skos properties (skos:exactMatch, skos:narrowMatch, skos:broadMatch, skos:related and possibly others) be used?

In my case they are not equivalent classes. First because MedDRA doesn't have definitions, so I am not sure they mean the same thing than I do. Second because the Brighton terms are less granular than the MedDRA ones, so one Brighton terms can "map_to" several MedDRA ones.

In my case I specifically want to be able to say something like "when you encounter that MedDRA term, consider you've seen the Brighton "mapped" one", and then use the Brighton hierarchy to classify. It may very well be that this is not a valid case either, and it would be great to have others input as to what is the best way to proceed. There was a webpage somewhere highlighting issues with skos (sorry I don't remember where it was), but I would prefer in any case to have something meaning what I need, which is "computational mapping" rather than semantic one. (and maybe mapping is a wrong term to use there, and it could be called "replacement" or else?)

Cheers,
Melanie

>
>
> All are welcome to attend - please let me know so I can add you to the skype call.
>
> Cheers,
> Melanie
>
> --
> --
> informatio...@googlegroups.com
> To change settings, visit
> http://groups.google.com/group/information-ontology
>
> ---
> You received this message because you are subscribed to the Google Groups "information-ontology" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to information-onto...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.

Download for free and get started troubleshooting in minutes.

http://p.sf.net/sfu/appdyn_d2d_ap2

[Christian Bölling]

> - 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)
>
> If they can be interchanged computationally the are owl:equivalentClass -es, or what is intended here? Could the established skos properties (skos:exactMatch, skos:narrowMatch, skos:broadMatch, skos:related and possibly others) be used?

In my case they are not equivalent classes. First because MedDRA doesn't have definitions, so I am not sure they mean the same thing than I do. Second because the Brighton terms are less granular than the MedDRA ones, so one Brighton terms can "map_to" several MedDRA ones.

In my case I specifically want to be able to say something like "when you encounter that MedDRA term, consider you've seen the Brighton "mapped" one", and then use the Brighton hierarchy to classify. It may very well be that this is not a valid case either, and it would be great to have others input as to what is the best way to proceed. There was a webpage somewhere highlighting issues with skos (sorry I don't remember where it was), but I would prefer in any case to have something meaning what I need, which is "computational mapping" rather than semantic one. (and maybe mapping is a wrong term to use there, and it could be called "replacement" or else?)

This use case is not clear to me. A relation that achieves inference on MedDRA classes in terms of corresponding Brighton classes is asserting MedDRA-class SubClassOf Brighton-class for the relevant pairs of classes. If you just want to say that there is this similar term in that other terminology then skos:broadMatch or skos:narrowMatch might be right for you. I think there is not much more semantics to those skos properties.

- Christian

[Melanie Courtot]

FYI - the call has been moved to 3pm EST.
Melanie

On 2013-05-02, at 11:29 AM, Melanie Courtot wrote:

> Hi all,
>
> Following the discussion at http://sourceforge.net/mailarchive/forum.php?thread_name=517AD020.1020505%40pcbi.upenn.edu&forum_name=obi-devel, Jie and I will have a call tomorrow 10am PST, 1 pm EST to try addressing attributions of terms and create needed annotation properties.
>
> Use 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)
> - 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.
> - 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)
>
> All are welcome to attend - please let me know so I can add you to the skype call.
>
> Cheers,
> Melanie


------------------------------------------------------------------------------

Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.

Download for free and get started troubleshooting in minutes.

http://p.sf.net/sfu/appdyn_d2d_ap2

[Matthew Brush]

Hello all.   Jie, Melanie, Alan, and myself had a call today regarding the need for more precise annotations for recording term provenance, and attribution of credit to those people or groups who request and/or provide terms to OBI.  The primary outcome  was three proposed IAO annotation properties.  Preliminary labels and rough definitions as follows:

 

1. 'term requested by':  used to record a person and/or group that requested a term in OBI.  This annotation can record a person (e.g. 'Yann Le Franc'), a group (e.g. 'ENCODE'), or both (i.e. a person and a group they represent).  May be able to add features to the tracker to gather this info with each tracker request, and generate this annotation.

 

2. 'term request URL' = URL of the term tracker for the term request (for cases when there is a tracker ticket associated with the request).  Label on this property subject to debate.

 

3. 'term adapted from':  used to reference a term from another ontology or vocabulary that was copied or adapted into an OBI term.  Annotation value would likely be the term ID (which should be resolvable to the group that provided it).  Alt, the group and the term could both be recorded.  Covers use cases such as IEDB or eagle-I  'donating'  terms  to OBI, where their metadata and logical axioms may or may not be altered.

 

One goal for such  properties is to enable tracking 'stakeholder' groups/communities linked to OBI through their providing or requesting terms.  Other provenance-related properties such as 'term editor' and 'definition source' annotations would remain as they are (but may require further clarification in reference to any new properties that result from the discussion above).

 

Feedback welcome via email or on an upcoming IAO/OBI-dev call.

 

Best, Matt

 

Matthew H. Brush

Research Associate

OHSU Ontology Development Group

Department of Medical Informatics and Clinical Epidemiology

Oregon Health and Science University

phone :  919-452-6914

fax :  503-346-6815

bru...@ohsu.edu

 

From: informatio...@googlegroups.com [mailto:informatio...@googlegroups.com] On Behalf Of Jenny Zheng
Sent: Thursday, May 02, 2013 12:09 PM
To: Melanie Courtot
Cc: Christian Bölling; information-ontology Discuss; obi-...@lists.sourceforge.net Developers
Subject: Re: [IAO] annotation properties for attribution of terms

 

About EFO terms, please see this tracker that submitted by EFO developers.
https://sourceforge.net/tracker/index.php?func=detail&aid=3199463&group_id=177891&atid=886178

Jie

[Ramona Walls]

These are great. Very happy to see the development of these IAO annotation properties.

I would like to see some clarification of "term adapted from". Perhaps you could provide a comment on why a term should be "adapted" from another ontology, rather than imported as is from that ontology. I know there was some discussion of it on this list already (I apologize that I didn't follow it too closely), so perhaps that could be the basis of the comment.

Thanks,

Ramona

------------------------------------------------------
Ramona L. Walls, Ph.D.
Scientific Analyst
The iPlant Collaborative
Thomas J. Keating Bioresearch Building

1657 East Helen St

Tucson, AZ  85721
tel: 520.626.1489
fax: 520.626.4824
rwa...@iplantcollaborative.org

[Jie Zheng]

Hi Ramona,

Here is a couple of cases that we don't want to use import mechanism.

1. MGED ontology (MO) was not built on the basis of BFO and align MO with BFO and make them available in OBI is part of OBI development process since OBI was proposed by FGED (former MGED) developers for making an OBO Foundry ontology covering functional genomics experiments including array one.

2. Some terms were created in other ontologies but should be in OBI scope. In this case, we would like to make them as OBI terms with OBI ids. For example, 'reagent' in REO, and some assay terms in EFO. They will be deprecated in their source ontologies and replaced by OBI terms. I think it is correct way to do for OBO Foundry ontologies. Each OBO Foundry ontology has a specific scope and the terms should be kept in the correct ontology.

Thanks,

Jie