phenopackets / phenopacket-reference-implementation

Reference java implementation for phenopackets
BSD 3-Clause "New" or "Revised" License
6 stars 9 forks source link

Should Environment have a TemporalRegion onset,offset and Severity? #30

Open julesjacobsen opened 8 years ago

julesjacobsen commented 8 years ago

For example if I want to say 'This person smoked all through their formative years' I would want to have some temporal association with the environment


---
id: "phenopkt#1"
title: "A male smoker"
persons:
- id: "person#1"
  label: "Joe Bloggs"
  sex: "M"
environment_profile:
- entity: "person#1"
  environment:
    description: "Smoked since birth, gave up as a teenager"
    types:
    - id: "EFO_0004318"
      label: "smoking behavior"
    onset:
      description: "started shortly after birth"
      start_time: "2000-01-01"
      end_time: "2000-01-01"
      types:
        - id: "HP:0003623"
          label: "Neonatal onset"
    offset:
      description: "finished as a teenager"
      end_time: "2015-01-01"
      types:
        - id: "HP:0003621"
          label: "Juvenile onset"
  evidence:
  - types:
    - id: "ECO:0000033"
      label: "TAS"
    source:
    - id: "PMID:23455423"

Environment exists as an extension of ClassInstance and can be expressed in conjunction with an Entity in an EnvironmentAssociation, however nothing can be said about the duration of the association, or the severity (e.g. heavy smoking vs sporadic social smoking).

/**
 * An instance of any kind of environmental exposure. Here environment is defined broadly,
 * and can include things as diverse as:
 * 
 *  - a history of smoking
 *  - living in a food desert
 *  - taking a particular type of drug at a certain regularity of a time interval
 *  - diet
 *  - microbiome
 * 
 * @author cjm
 *
 */
public class Environment extends ClassInstance {
}

Environment is also used in Condition, where a Condition has (presumably occurrs in) an Environment. The Condition also has a TemporalRegion onset,offset and ConditionSeverity.

public abstract class Condition extends ClassInstance {

    @JsonProperty("has_location")
    @JsonPropertyDescription("the location in an organism or cell in which the phenotype manifests")
    @JsonldProperty("http://purl.obolibrary.org/obo/BFO_0000066")
    private OrganismalSite hasLocation;

    @JsonProperty("onset")
    @JsonPropertyDescription("the time region in which the condition is first manifest")
    private TemporalRegion timeOfOnset;

    @JsonProperty("offset")
    @JsonPropertyDescription("the time region in which the condition ceases to manifest")
    private TemporalRegion timeOfFinishing;

    @JsonProperty("severity")
    @JsonPropertyDescription("the degree to which the phenotype is manifest, related to the concept of expressivity, see http://www.ncbi.nlm.nih.gov/books/NBK22090/")
    private ConditionSeverity severity;

    @JsonProperty("environment")
    @JsonPropertyDescription("the environment in which the phenotype is expressed")
    private Environment environment;
...

So Environment clearly isn't a Condition as currently defined. It looks like it should belong in the Condition package, but only if it is always assiciated with a Condition. Conditions such as lung cancer can occur years after a person has given-up smoking/ being exposed to asbestos so the causative environment doesn't necessarily occur in exactly the same time-frame as the condition. In fact it probably never does, the time delay may only be a few seconds in the case of analphylactic shock for instance.

cmungall commented 8 years ago

Agreed.

  1. have Condition and Environment inherit from a new class that groups temporally occurring things (Occurrent or Finding)
  2. rename Condition to something more general (e.g. Finding) and have Environment inherit from this
  3. repeat the code; perhaps sharing the same interface

I would opt for 1, but am conscious of having too many levels in the hierarchy. Justification for not overloading (option 2):