Add axioms for chemical properties

[cmungall]

The following terms should be linked to CHEBI to make them interoperable with other ontologies:

  is_a AGRO_00000150 ! seeding area density *** 
  is_a AGRO_00000152 ! liming material area density *** 
  is_a AGRO_00000154 ! plant reproductive material area density *** 
  is_a AGRO_00000156 ! fertilizer area density *** 
  is_a AGRO_00000158 ! nitrogen area density *** 
  is_a AGRO_00000160 ! phosphorus area density *** 
  is_a AGRO_00000162 ! potassium area density *** 
  is_a AGRO_00000164 ! sulfur area density *** 
  is_a AGRO_00000166 ! chemical pest control material area density *** 
  is_a AGRO_00000168 ! nitrate area density *** 
  is_a AGRO_00000169 ! ammonium area density *** 
  is_a AGRO_00000170 ! calcium area density *** 
  is_a AGRO_00000174 ! magnesium area density *** 
  is_a AGRO_00000175 ! iron area density *** 
  is_a AGRO_00000176 ! zinc area density *** 
  is_a AGRO_00000177 ! copper area density *** 
  is_a AGRO_00000178 ! boron area density *** 
  is_a AGRO_00000179 ! molybdenum area density *** 
  is_a AGRO_00000180 ! manganese area density *** 
  is_a AGRO_00000188 ! chlorine area density *** 

Here is the way I would go about doing this:

1. Define a design pattern for each property or group of properties (e.g. area density)
2. Explore an automation technique to generate this part of the ontology from CSVs
3. If it turns out that manual editing in Protege is still preferred, we should still add axioms using the pattern, and we can use the pattern for validation

Some examples:
https://github.com/obophenotype/bio-attribute-ontology/tree/master/src/ontology/patterns

Sorry if this sounds a bit obscure, I can give a fuller explanation in time. @marieALaporte is familiar with the system

[cmungall]

And the datum and quality hierarchies are currently not linked. They should be - again the DP approach can automate this

(although I personally would argue that both datum and quality hierarchies is overinflation of terms)

[marieALaporte]

(although I personally would argue that both datum and quality hierarchies is overinflation of terms)

@cmungall How would you then link the methods and units to the qualities? We need to keep in mind that agrO will be used for designing a fieldbook, and thus we'd like to be able to get, for instance, all the methods that apply for a given quality. That's the reason why we have both datum and quality hierarchies.

[cmungall]

Can we just like the methods directly to the quality?

[marieALaporte]

Yes, maybe. Using which property?
We defined the CO property 'method_of' for that. I am not familiar enough with RO to know if something like that already exists.

But at the end of the day, we needed in CO precomposed terms for the fieldbook... That's an other argument for the datum hierarchy. But since we haven't really started to work on the fieldbook, we can maybe figure out a different way to do things. Any idea?

[marieALaporte]

@cmungall 2 questions.
1- I am reusing your apply-pattern.py script to create the DP in AgrO. What is get_applies_pattern_property() for? The prefix of the annotation property it creates is not really standard. Can I get rid of that ?

2- I am also wondering if there is a way to create 2 type of classes, using the same yaml file. Let's take an example. I want to create the measurement datum 'air temperature measurement' (this is an example, I know that this measurement datum should probably be in ENVO, if ENVO is interested in having defined measurement datum). The DP will look like something like:

('has method' some 'air temperature measurement protocol')
and (IAO_0000039 some 'degree Celsius')
and (IAO_0000136 some 'temperature of air')

I would like to create the 'air temperature measurement protocol' class at the same time I create 'air temperature measurement'. We have a textual definition for 'air temperature measurement protocol' that we would like to add too. Can I do that in one yaml file or I need to do that in two steps?

[KrishnaTO]

Added dosdp patterns for terms in PR #123.