Planteome / plant-ontology

Repository for the Plant Ontology
Creative Commons Attribution 4.0 International
57 stars 17 forks source link

add top-level plant ontology term #436

Open planteome-user opened 12 years ago

planteome-user commented 12 years ago

as I was updating PO in the sol genomics database, I've ran into an issue with participates_in relationship, which creates references between terms in plant_anatomy node and 'sporophyte phase' or 'gametophyte phase' from the growth stages node. (e.g. http://plantontology.org/amigo/go.cgi?xpand=[PO:0025025](http://purl.obolibrary.org/obo/PO_0025025)&search\_constraint=terms&query=[PO:0025025](http://purl.obolibrary.org/obo/PO_0025025)&session\_id=9390b1327425114&view=details&show\_associations=list)

Since the 2 PO components are now merged into one plant_ontology file, and there are relationships between terms of these 2 components, would it make sense to have one root term called 'plant ontology' ? Currently the ontology has 2 roots, and the PO browser top level term displays as 'all'.

On the technical side, I am not sure how the ontology is loaded into Amigo, but the gmod loader, which I maintain assumes each namespace is separate without relationships between terms (as in GO and its 3 components). This behavior could be changed, but I think one top level root for PO should be considered .

Reported by: *anonymous

Original Ticket: obo/plant-ontology-po-term-requests/436

planteome-user commented 12 years ago

I think it is a good idea to add a top level term (or terms) for the PO.

We should check with Barry and Chris on the best way to do this, but I think it would be good to incorporate some of the BFO and CARO terms. For example:

BFO:entity >BFO:continuant >>BFO:independent continuant >>>CARO:anatomical entity >>>>PO:plant anatomical entity >BFO:occurent >>BFO:processual occurent >>>PO:plant structure development stage

Original comment by: rlwalls2008

planteome-user commented 12 years ago

I suggest we make a root term "plant entity' This would be consistent with BFO and avoid the problems above.

Original comment by: cooperl09

planteome-user commented 12 years ago

Hi Naama, We have had a number of discussions regarding the creation of the top level term in the PO and so far it does not seem like it is going to happen, at least in the short term.

I have been thinking about your problem and one solution would be to load the two individual branch files. That way you would get all the relations, except the participates_in which links the two branches of the ontology. The files are: po_anatomy.obo and po_temporal.obo. These correspond to the latest release.

Original comment by: cooperl09

planteome-user commented 12 years ago

Naama,

You say that "the gmod loader ... assumes each namespace is separate without relationships between terms". Even if we were to add a top level term, terms from the two branches would still have different namespaces, unless we were to change the whole ontology to have one namespace. Given the separate namespaces, would creating a top level term solve your problem?

Also note that as they currently stand, po_anatomy.obo and po_temporal.obo only have is_a and part_of relations. If you use those files, you would lose all other relations, not just participates_in and has_participant.

Original comment by: rlwalls2008

planteome-user commented 12 years ago

The complete hierarchy would be:

BFO:entity --BFO:material entity ----PO:plant anatomical entity --BFO:occurrent ----PO:stage

However, I don't recommend PO imports or mireots BFO. This should be an external bridge ontology mapping to BFO.

There's no need to have a shared root in the main PO file. It certainly wouldn't be "plant ontology", as a plant is not a subclass of plant ontology.

AmiGO1 has a bug where it expects 1 root, so the fake "All" is added by default.

Original comment by: cmungall

planteome-user commented 12 years ago

sorry didn't read full thread my answer was redundant with Ramona's.

Original comment by: cmungall

planteome-user commented 12 years ago

re: "AmiGO1 has a bug where it expects 1 root, so the fake "All" is added by default."

Strangely enough, we have recently noticed that AmiGO also adds the fake 'All' superclass even when there IS a top level term.
For example see: http://palea.cgrb.oregonstate.edu/trait\_ontology/cgi-bin/trait\_amigo/browse.cgi?session\_id=1852amigo1337966110

Original comment by: cooperl09