text:
<?xml version="1.0"?>
<rdf:RDF xmlns="http://purl.obolibrary.org/obo/x-bfo.owl#"
     xml:base="http://purl.obolibrary.org/obo/x-bfo.owl"
     xmlns:obo="http://purl.obolibrary.org/obo/"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:oboInOwl="http://www.geneontology.org/formats/oboInOwl#">
    <owl:Ontology rdf:about="http://purl.obolibrary.org/obo/upheno/mammal.owl">
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/mp.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/hp.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/hp-mp/mp_hp-align-equiv.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/upheno_root_alignments.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/imports/go_phenotype.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/imports/mpath_phenotype.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/imports/nbo_phenotype.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/imports/uberon_phenotype.owl"/>

        <!-- <owl:imports rdf:resource="http://purl.obolibrary.org/obo/mp/mp-to-hp-match-best.owl"/> -->
    </owl:Ontology>

</rdf:RDF>

<!-- Generated by the OWL API (version 0.5.1-SNAPSHOT) http://owlapi.sourceforge.net -->

repo_name: obophenotype/upheno

repo_language: Makefile

mime_type: text/plain


text:
OBO=http://purl.obolibrary.org/obo
WGET= wget --no-check-certificate
all: all_imports

#test: reasoner-test-mammal reasoner-test-vertebrate reasoner-test-metazoa
# TODO: determine where unsats in metazoa are coming from
test: test-patterns reasoner-test-mammal reasoner-test-vertebrate

reasoner-test-%: %.owl
	owltools $< --run-reasoner -r elk -u > $@.out && echo ok || (tail -100 $@.out ; exit 1)
explanations-%.txt: %.owl
	owltools $< --run-reasoner -r elk -u -e > $@.out && echo ok || (tail -100 $@.out ; exit 1)

# local copies, for seeding
mp-edit.owl:
	$(WGET) $(OBO)/mp/mp-edit.owl -O $@
hp-edit.owl:
	$(WGET)  $(OBO)/hp/hp-edit.owl -O $@

# ----------------------------------------
# Module extraction / Imports generation
# ----------------------------------------
#
# We create shared modules for the combined set of phenotype
# ontologies
#
# Uses OWLAPI Module Extraction code
#
# Type 'make imports/X_import.owl' whenever you wish to refresh the import for an ontology X. This is when:
#
#  1. X has changed and we want to include these changes
#  2. We have added onr or more new IRI from X into any of the xp files
#
# You should NOT edit these files directly, changes will be overwritten.
#
# If you want to add something to these, edit the xp obo file and add an axiom with a IRI from X. You don't need to add any information about X.
#
# **Note that imports are shared by all projects**
# this means that any one import will be larger than is strictly required for any one species, but there are advantages to sharing here

# Base URI for local subset imports
UPHENO = $(OBO)/upheno

# Ontology dependencies. TODO - nbo
IMPORTS = pato uberon chebi pr go doid mpath nbo

# Make this target to regenerate ALL
all_imports: all_imports_owl all_imports_obo
all_imports_owl: $(patsubst %, imports/%_import.owl,$(IMPORTS))
all_imports_obo: $(patsubst %, imports/%_import.obo,$(IMPORTS))

KEEPRELS = BFO:0000050 BFO:0000051 RO:0002202 immediate_transformation_of

# Create an import module using the OWLAPI module extraction code via OWLTools.
# We use the standard catalog, but rewrite the import to X to be a local mirror of ALL of X.
# After extraction, we further reduce the ontology by creating a "mingraph" (removes all annotations except label) and by

#imports/wbbt_import.owl: wbphenotype/wbphenotype-equivalence-axioms-subq-ubr.owl mirror/wbbt.owl
#	owltools  $(USECAT) --map-ontology-iri $(UPHENO)/wbbt_import.owl mirror/wbbt.owl $< --merge-imports-closure mirror/$*.owl --add-imports-from-support  --extract-module -s $(OBO)/$*.owl -c --remove-axiom-annotations --make-subset-by-properties $(KEEPRELS) --set-ontology-id $(UPHENO)/$@ -o $@

IMPORT_REQUESTS = imports/imports_requests.owl

# GENERIC:
imports/%_import.owl: imports/upheno-preimporter.owl $(IMPORT_REQUESTS) mirror/%.owl mp-edit.owl
	owltools  $(USECAT) --map-ontology-iri $(UPHENO)/$*_import.owl mirror/$*.owl $< --merge-imports-closure mirror/$*.owl --add-imports-from-support  --extract-module -s $(OBO)/$*.owl -c --remove-axiom-annotations --make-subset-by-properties -f $(KEEPRELS) -o $@.tmp && owltools $@.tmp --set-ontology-id $(UPHENO)/$@ -o $@

imports/ro_import.owl: mirror/ro.owl mp-edit.owl hp-edit.owl zp.owl mirror/uberon-bridge-to-zfa.owl mirror/cl-bridge-to-zfa.owl mirror/uberon-bridge-to-wbbt.owl mirror/cl-bridge-to-wbbt.owl mirror/uberon-bridge-to-fbbt.owl mirror/cl-bridge-to-fbbt.owl
	robot merge --input mp-edit.owl --input hp-edit.owl --input zp.owl --input mirror/uberon-bridge-to-zfa.owl --input mirror/cl-bridge-to-zfa.owl --input mirror/uberon-bridge-to-wbbt.owl --input mirror/cl-bridge-to-wbbt.owl --input mirror/uberon-bridge-to-fbbt.owl --input mirror/cl-bridge-to-fbbt.owl --input wbphenotype/wbphenotype-equivalence-axioms-edit.owl query --select sparql/terms.rq terms.txt &&\
	robot extract --method BOT --input mirror/ro.owl --term-file terms.txt annotate --ontology-iri $(UPHENO)/$@ --output $@

imports/zfa_import.owl: mirror/zfa.owl mirror/uberon-bridge-to-zfa.owl mirror/cl-bridge-to-zfa.owl
	robot merge --input mirror/zfa.owl --input mirror/uberon-bridge-to-zfa.owl --input mirror/cl-bridge-to-zfa.owl query --format ttl --construct sparql/extract-zfa-lite.rq zfa-lite.ttl &&\
	robot annotate --input zfa-lite.ttl --ontology-iri $(UPHENO)/$@ -o $@ && rm -f zfa-lite.ttl

# clone remote ontology locally, perfoming some excision of relations and annotations
mirror/%.owl:
	owltools $(OBO)/$*.owl --remove-annotation-assertions -l --remove-dangling-annotations  --make-subset-by-properties -f $(KEEPRELS) --extract-mingraph --set-ontology-id $(OBO)/$*.owl -o $@
# uberon-ext is actually uberon+cl
mirror/uberon-ext.owl:
	owltools $(OBO)/uberon/ext.owl --merge-imports-closure -o $@

mirror/ro.owl:
	$(WGET) $(OBO)/ro.owl -O $@

# Combine mpath and ncit into one import
# See: https://github.com/obophenotype/upheno/issues/166
mirror/mpath.owl:
	owltools https://raw.githubusercontent.com/monarch-initiative/monarch-disease-ontology/master/src/mpath/linked-pathology.obo -o $@

# See https://github.com/obophenotype/upheno/issues/159
mirror/nbo.obo:
	$(WGET) $(OBO)/nbo.obo -O $@.tmp && egrep -v '^(import|property_value)' $@.tmp > $@
mirror/nbo.owl: mirror/nbo.obo
	owltools $<  --remove-annotation-assertions -l --remove-dangling-annotations  --make-subset-by-properties -f $(KEEPRELS) --extract-mingraph --set-ontology-id $(OBO)/nbo.owl -o $@.tmp && perl -npe 's@obo/nbo.owl/@obo/@' $@.tmp > $@

mirror/wbbt.owl:
	owltools $(OBO)/uberon/basic.owl $(OBO)/cl.owl $(OBO)/wbls.owl $(OBO)/wbbt.owl $(OBO)/uberon/bridge/uberon-bridge-to-wbbt.owl $(OBO)/uberon/bridge/cl-bridge-to-wbbt.owl $(OBO)/ncbitaxon/subsets/taxslim.owl --merge-support-ontologies --remove-annotation-assertions -l --remove-dangling-annotations --make-subset-by-properties $(KEEPRELS)  --set-ontology-id $(OBO)/wbbt.owl -o $@
###	owltools $(OBO)/uberon/ext.owl --remove-annotation-assertions -l --remove-dangling-annotations --make-subset-by-properties $(KEEPRELS) --set-ontology-id $(OBO)/uberon.owl -o $@
###	owltools  $(OBO)/wbls.owl $(OBO)/wbbt.owl --merge-support-ontologies --remove-annotation-assertions -l --remove-dangling-annotations --make-subset-by-properties $(KEEPRELS)  --set-ontology-id $(OBO)/wbbt.owl -o $@
mirror/go.owl:
	owltools $(OBO)/go/extensions/go-plus.owl   --merge-imports-closure --merge-support-ontologies --remove-annotation-assertions -l --remove-dangling-annotations  --make-subset-by-properties -f $(KEEPRELS) --extract-mingraph --set-ontology-id $(OBO)/go.owl -o $@
mirror/pr.obo:
	$(WGET) $(OBO)/pr.obo -O $@.tmp && obo-grep.pl -r 'id: PR:' $@.tmp > $@
mirror/pr.owl: mirror/pr.obo
	owltools $< --remove-dangling --set-ontology-id $(OBO)/pr.owl -o $@

mirror/zfa.owl:
	mkdir -p mirror && wget $(OBO)/zfa.owl -O $@

mirror/uberon-bridge-to-zfa.owl:
	mkdir -p mirror && wget $(OBO)/uberon/bridge/uberon-bridge-to-zfa.owl -O $@

mirror/cl-bridge-to-zfa.owl:
	mkdir -p mirror && wget $(OBO)/uberon/bridge/cl-bridge-to-zfa.owl -O $@

.PRECIOUS: mirror/%.owl

#imports/ro_import.owl: mirror/ro.owl imports/upheno-preimporter.owl
#	owltools  $(USECAT) --map-ontology-iri $(UPHENO)/ro_import.owl mirror/ro.owl imports/upheno-preimporter.owl --merge-imports-closure mirror/ro.owl  --add-imports-from-supports  --extract-module -s $(OBO)/ro.owl -c --extract-mingraph --set-ontology-id $(UPHENO)/$@ -o $@

imports/so_import.owl:
	owltools  $(USECAT) $< $(UPHENO)/data/human-genes.owl $(OBO)/so.owl --add-imports-from-supports --extract-module -s $(OBO)/so.owl -c --extract-mingraph --remove-annotation-assertions -l -d -s --make-subset-by-properties -f // --set-ontology-id $(UPHENO)/$@ -o $@

imports/%_import.obo: imports/%_import.owl
	owltools $< -o -f obo $@

imports/%_phenotype.obo: imports/%_phenotype.owl
	owltools $< --assert-inferred-subclass-axioms --removeRedundant --allowEquivalencies  -o -f obo $@

external/uberon/%.owl:
	echo $@

external/mirror/%.owl:
	$(WGET) $(OBO)/$*.owl -O $@

# ----------------------------------------
# PATTERNS
# ----------------------------------------
test-patterns:
	cd src/patterns && make test

# ----------------------------------------
# GROUPINGS
# ----------------------------------------
util/blacklist.js:
	owljs -i tools/make-blacklist.js

#imports/%_phenotype.owl: imports/%_import.owl ./tools/blacklist.js
#	owljs -i tools/make-grouping-classes.js

imports/%_import.tsv: imports/%_import.owl
	owltools $< --export-table $@.tmp && cut -f1,2 $@.tmp > $@

imports/%_entities.tsv: imports/%_import.tsv
	 ./tools/make-entity-table.pl $< imports/entity_blacklist.tsv  > $@.tmp && mv $@.tmp $@

imports/%_phenotype.omn: imports/%_entities.tsv
	apply-pattern.py -p patterns/grouping_phenotype.yaml -i $< > $@.tmp && mv $@.tmp $@
imports/%_phenotype.owl: imports/%_phenotype.omn
	owltools $< --set-ontology-id $(UPHENO)/$@ -o $@

##

zp.owl:
	wget $(OBO)/upheno/zp.owl -O $@
zp.obo:
	owltools $(OBO)/upheno/zp.owl --add-ontology-annotation http://www.geneontology.org/formats/oboInOwl#logical-definition-view-relation has_part --add-obo-shorthand-to-properties -o -f obo --no-check $@

## ----------------------------------------
## MERGES
## ----------------------------------------

# Merged
%-m.owl: %.owl
	owltools  --use-catalog $< --merge-imports-closure  -o $@
.PRECIOUS: %-m.owl

# Reasoned
%-r.owl: %-m.owl
	owltools  $<  --reasoner elk  --remove-disjoints --assert-inferred-subclass-axioms --allowEquivalencies -o tmp-$@ && robot reduce --named-classes-only true --input tmp-$@ --output $@
#	https://github.com/obophenotype/upheno/issues/162
#	robot merge -c true -i $< reason -r elk  reduce -o $@
.PRECIOUS: %-r.owl

# Translate probabilistic axioms from text mining using inferred ontology as background
mp-hp-kboom.owl: hp-mp/mp_hp-ptable.tsv mp-hp-r.owl
	kboom --experimental  --splitSize 50 --max 3 -m linked-rpt.md -j linked-rpt.json -n -o $@ -t $^

# Create a view, incorporating kboom inferred axioms
mp-hp-view.owl: mp-hp-r.owl
	owltools $(USECAT) $< mp-hp-kboom.owl --merge-support-ontologies --make-subset-by-properties -f // --reasoner-query -r elk MP_0000001  --make-ontology-from-results $(OBO)/upheno/$@ -o $@
.PRECIOUS: mp-hp-view.owl

mp-hp-view.obo: mp-hp-view.owl
	owltools $< -o -f obo $@.tmp && grep -v ^owl-axioms $@.tmp > $@

reports/mp-hp-equivalent-classes.tsv: mp-hp-view.owl
	arq --query sparql/intra-ontology-equivalence.rq --data mp-hp-view.owl --results TSV > $@.tmp && mv $@.tmp $@

reports/mp-mp-equivalent-classes.tsv: reports/mp-hp-equivalent-classes.tsv
	egrep 'MP.*MP' $< > $@
reports/hp-hp-equivalent-classes.tsv: reports/mp-hp-equivalent-classes.tsv
	egrep 'HP.*HP' $< > $@

## ----------------------------------------
## MAPPINGS
## ----------------------------------------

%-compute.obo: %.owl
	owltools $(USECAT) $< --merge-imports-closure --remove-axiom-annotations --remove-disjoints --remove-abox --remove-annotation-assertions -l --assert-inferred-subclass-axioms --always-assert-super-classes --removeRedundant --allowEquivalencies --make-subset-by-properties -f // -o -f obo --no-check $@
.PRECIOUS: %-compute.obo

all_mappings: mappings/zp-to-hp-match.tbl mappings/hp-to-zp-match.tbl mappings/hp-to-mp-match.tbl
mappings/%-match.tbl: vertebrate-compute.obo
	owltools $(USECAT) $< --make-default-abox --fsim-compare-atts -p mappings/$*-sim.properties -o $@.tmp && mv $@.tmp $@

mappings/hp-to-wbphenotype-match.tbl: metazoa-compute.obo
	owltools $(USECAT) $< --make-default-abox --fsim-compare-atts -p mappings/hp-to-wbphenotype-sim.properties -o $@.tmp && mv $@.tmp $@

mappings/%-bestmatches.tsv: mappings/%-match.tbl
	./tools/extract-bestmatches.pl $< > $@.tmp && mv $@.tmp $@


text:
<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [
    <!ENTITY owl "http://www.w3.org/2002/07/owl#" >
    <!ENTITY obo "http://purl.obolibrary.org/obo/" >
    <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
    <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
    <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
    <!ENTITY oboInOwl "http://www.geneontology.org/formats/oboInOwl#" >
]>

<rdf:RDF xmlns="http://purl.obolibrary.org/obo/x-bfo.owl#"
     xml:base="http://purl.obolibrary.org/obo/x-bfo.owl"
     xmlns:obo="http://purl.obolibrary.org/obo/"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:oboInOwl="http://www.geneontology.org/formats/oboInOwl#">
    <owl:Ontology rdf:about="http://purl.obolibrary.org/obo/upheno/vertebrate.owl">
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/uberon/bridge/cl-bridge-to-zfa.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/uberon/bridge/uberon-bridge-to-zfa.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/uberon/bridge/cl-bridge-to-xao.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/uberon/bridge/uberon-bridge-to-xao.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/mammal.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/imports/uberon_import.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/vt.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/zp.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/xpo.owl"/>
    </owl:Ontology>

    <!--
    ///////////////////////////////////////////////////////////////////////////////////////
    //
    // Classes
    //
    ///////////////////////////////////////////////////////////////////////////////////////
     -->

    <!-- http://purl.obolibrary.org/obo/UPHENO_0000501 -->

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/UPHENO_0000501">
        <rdfs:label>accelerated feather growth</rdfs:label>
    </owl:Class>

    <!-- http://purl.obolibrary.org/obo/UPHENO_0000502 -->

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/UPHENO_0000502">
        <rdfs:label>curved upper beak</rdfs:label>
    </owl:Class>

    <!-- http://purl.obolibrary.org/obo/UPHENO_0000503 -->

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/UPHENO_0000503">
        <rdfs:label>short upper beak</rdfs:label>
    </owl:Class>

    <!-- http://purl.obolibrary.org/obo/UPHENO_0000504 -->

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/UPHENO_0000504">
        <rdfs:label>absent feather barbule</rdfs:label>
    </owl:Class>

    <!-- http://purl.obolibrary.org/obo/UPHENO_0000505 -->

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/UPHENO_0000505">
        <rdfs:label>decreased wing length</rdfs:label>
    </owl:Class>

    <!-- http://purl.obolibrary.org/obo/UPHENO_0000506 -->

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/UPHENO_0000506">
        <rdfs:label>increased filoplume feather length</rdfs:label>
    </owl:Class>
</rdf:RDF>

<!-- Generated by the OWL API (version 3.4.2) http://owlapi.sourceforge.net -->


text:
<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [
    <!ENTITY owl "http://www.w3.org/2002/07/owl#" >
    <!ENTITY obo "http://purl.obolibrary.org/obo/" >
    <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
    <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
    <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
    <!ENTITY oboInOwl "http://www.geneontology.org/formats/oboInOwl#" >
]>

<rdf:RDF xmlns="http://purl.obolibrary.org/obo/x-bfo.owl#"
     xml:base="http://purl.obolibrary.org/obo/x-bfo.owl"
     xmlns:obo="http://purl.obolibrary.org/obo/"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:oboInOwl="http://www.geneontology.org/formats/oboInOwl#">
    <owl:Ontology rdf:about="http://purl.obolibrary.org/obo/upheno.owl">
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/upheno/metazoa.owl"/>
    </owl:Ontology>
</rdf:RDF>

<!-- Generated by the OWL API (version 3.4.2) http://owlapi.sourceforge.net -->


text:
site_name: Unified Phenotype Ontology
theme: readthedocs
nav:
  - Getting started: index.md
  - Cite: cite.md
  - About uPheno: about.md
  - uPheno community effort:
      - Meetings: organization/meetings.md
  - How-to guides:
      - Standard ODK workflows:
          - Overview: odk-workflows/index.md
          - Editors Workflow: odk-workflows/EditorsWorkflow.md
          - Release Workflow: odk-workflows/ReleaseWorkflow.md
          - Manage your ODK Repository: odk-workflows/RepoManagement.md
          - Setting up Docker for ODK: odk-workflows/SettingUpDockerForODK.md
          - Manage imports: odk-workflows/UpdateImports.md
          - Manage documentation: odk-workflows/ManageDocumentation.md
          - Manage Continuous Integration: odk-workflows/ContinuousIntegration.md
      - Contributing: contributing.md
      - Advanced Phenotype Ontology Editor workflows:
          - How to run a uPheno 2 release: howto/run-upheno2-release.md
          - How to set up s3 for uploading upheno data files: howto/set-up-s3.md
          - Add custom uPheno Makefile: howto/custom-upheno-makefile.md
          - Add the uPheno direct relation extension: howto/add-relation-extension.md
          - Pattern merge - replace workflow: howto/pattern-merge-replace-workflow.md
          - Phenotype Ontology Editors' Workflow: howto/editors_workflow.md
  - Tutorials:
      - Using uPheno in Data Analysis: tutorials/analysis.md
      - Using uPheno in Curation: tutorials/curation.md
      - Using uPheno for Grouping Data: tutorials/grouping.md
  - Key topics:
    - EQ modelling:
      - Overview of EQ modelling: key-topics/entity_quality_modelling.md
      - Abnormal phenotypes: key-topics/modelling/abnormal.md
      - Absence modelling: key-topics/modelling/absence.md
      - Traits and phenotypes: key-topics/modelling/traits.md
    - The Phenotype Reconciliation Effort: key-topics/reconciliation_effort.md
    - Use Cases:
      - Cross-species reasoning: key-topics/use-cases/cross_species_reasoning.md
  - Reference:
    - Your ODK Repository Overview: odk-workflows/RepositoryFileStructure.md
    - Components:
      - Overview: reference/components.md
      - Drosophila Phenotype Ontology: reference/components/dpo.md
      - Fission Yeast Phenotype Ontology: reference/components/fypo.md
      - Human Phenotype Ontology: reference/components/hp.md
      - Mammalian Phenotype Ontology: reference/components/mp.md
      - C. elegans Phenotype Ontology: reference/components/wbphenotype.md
      - Zebrafish Phenotype Ontology: reference/components/zp.md
    - Imports:
      - Overview: reference/imports.md
      - Gene Ontology: reference/imports/go.md
      - Uberon: reference/imports/uberon.md
      - PATO: reference/imports/pato.md
    - Mappings:
      - Overview: reference/mappings.md
      - MP-HP: reference/mappings/mp_hp.md
    - Quality Control:
      - Overview: reference/qc.md
      - Standard OBO checks: reference/qc/odk_checks.md
    - Design Patterns:
      - Design Patterns Overview: reference/patterns.md


text:
![Build Status](https://github.com/obophenotype/upheno/workflows/CI/badge.svg)

<img src="https://raw.githubusercontent.com/jmcmurry/closed-illustrations/master/logos/upheno-logos/upheno-logo_black-banner.svg?sanitize=true" width="400px"/>

This repository contains common files ontologies and workflows shared
between multiple phenotype ontologies.

See the [wiki](https://github.com/obophenotype/upheno/wiki) for additional documentation

## Inter-ontology Closest Matches

 * [hp-to-mp-bestmatches.tsv](mappings/hp-to-mp-bestmatches.tsv)
 * [hp-to-zp-bestmatches.tsv](mappings/hp-to-zp-bestmatches.tsv)
 * [hp-to-wbphenotype-bestmatches.tsv](mappings/hp-to-wbphenotype-bestmatches.tsv)

See [mappings/README.md](mappings/README.md) for explanation of fields

## Background

Many databases use their own ontology geared towards their species of
interest or an area of interest. The purpose of this repository is to
provide a mechanism for integrating these together into a unified
phenotype ontology. We do this primarily through *OWL Axiomatization*
and *OWL Reasoning*.

This approach takes advantages of the fact that phenotype ontologies
typically follow a compositional structure. If each contributing
ontology makes the semantics of this composition transparent through
*OWL Axioms* then a reasoner can piece the ontologies together and
find the overarching classification.

For example, if a phenotype ontology `A` contains a class for `limb size`,
and also provides an OWL axiom that maps onto a decomposed form, for
example:

 * `A:limb size` equivalentTo `pato:size` and `inheres in` some `limb`

And if phenotype ontology `B` has a class `short forelimb`, with axiom:

 * `B:short forelimb` equivalentTo `pato:short` and `inheres in` some `forelimb`

Then a reasoner can infer that `B:short forelimb` is a subclass of `A:limb size`

The OWL Axioms we use follow a design pattern called `EQ` or `Entity-Quality` descriptions.

Furthermore, if a database `C` provides a row for a genotype described
compositionally, the placement of these phenotypes can also be
inferred.

For background on the original formulation, see:

C J Mungall, Georgios Gkoutos, Cynthia Smith, Melissa Haendel, Suzanna Lewis, Michael Ashburner (2010) [Integrating phenotype ontologies across multiple species](http://genomebiology.com/2010/11/1/R2) _Genome Biology_ 11 (1)

## Exploring uPheno

The Monarch website uses uPheno to group data from multiple species. See for example: https://monarchinitiative.org/phenotype/MP:0003631

You can also query this using Monarch SciGraph services: https://scigraph-ontology.monarchinitiative.org/scigraph/docs/

To understand the mechanics of how uPheno works, we recommend opening
the OWL in Protege and exploring with a fast reasoner such as Elk
running

The remainder of these docs assumes some familiarity with Protege/OWL

We provide various modules:

 * mammal.owl
 * vertebrate.owl
 * metazoa.owl

## Contributing Ontologies

 * [mp](http://obofoundry.org/ontology/mp.html)* - mouse // mammal.owl
 * [hp](http://obofoundry.org/ontology/hp.html)* - human // mammal.owl
 * zp - zebrafish** // vertebrate.owl
 * [wbphenotype](http://obofoundry.org/ontology/wbphenotype.html) - C elegans // metazoa.owl
 * [dpo](http://obofoundry.org/ontology/dpo.html)* - Drosophila  // metazoa.owl
 * [fypo](http://obofoundry.org/ontology/fypo.html)* - Fission Yeast // eukaryote.owl

`*` -- this ontology provides their own OWL axiomatization
`**` -- separately generated ontology

## External Imports Modules

The OWL axiomatization depends on a number of external ontologies, including

 * pato
 * uberon
 * cl
 * species-specific AOs
 * go
 * chebi

Many of these are large, so we create *import modules* in the upheno ontology purl space

See the [imports](imports) directory

## PURLs

This ontology has the OBO PURL `upheno`

A redirect at [obolibrary.org](https://github.com/OBOFoundry/purl.obolibrary.org/) maps

 * http://purl.obolibrary.org/obo/upheno/ ==> this repository on github

## History

Previously we had various things on:

 * https://code.google.com/p/phenotype-ontologies

This was split across multiple github repos

 * {data,server} ==> https://github.com/monarch-initiative/monarch-owlsim-data
 * src/ontology
    * mp ==> https://github.com/obophenotype/mammalian-phenotype-ontology/
    * hp ==> https://github.com/obophenotype/human-phenotype-ontology/ (may change)
    * imports/ ==> https://github.com/obophenotype/upheno
    * monarch.owl ==> https://github.com/monarch-initiative/monarch-ontology
    * zp.owl ==> http://compbio.charite.de/jenkins/job/zp-owl/
 * wiki ==> https://github.com/obophenotype/upheno ([docs/](docs/) directory)

 ## Design patterns

 The design patterns are grouped into three higher level groupings:
 1. anatomical entity (anatomical entities (Uberon), cells (CL))
 2. cellular component (from GO)
 3. chemical entity (includes chemicals (CHEBI), proteins (PRO))

Current structure of uPheno 1:

1. mp-hp-kboom.owl: OBSOLETE
1. mp-hp.ow: OBSOLETE
1. upheno_root_alignments.owl: OBSOLETE

## Current uPheno structure
1. upheno.owl (TODO needs to be obsoleted):
   1. metazoa.owl
      1. Worm
         1. OBO:uberon/bridge/cl-bridge-to-wbbt.owl
         1. OBO:uberon/bridge/uberon-bridge-to-wbbt.owl
         1. OBO:wbphenotype/wbphenotype-full.owl
      1. Fly
         1. OBO:uberon/bridge/cl-bridge-to-fbbt.owl
         1. OBO:uberon/bridge/uberon-bridge-to-fbbt.owl
         1. OBO:dpo.owl
         1. OBO:upheno/dpo/dpo-bridge.owl
         1. OBO:upheno/imports/fbbt_phenotype.owl
      1. OBO:upheno/vertebrate.owl
         1. Zebrafish:
           1. OBO:zp.owl
           1. OBO:uberon/bridge/cl-bridge-to-zfa.owl
           1. OBO:uberon/bridge/uberon-bridge-to-zfa.owl
           1. OBO:upheno/imports/zfa_import.owl
         1. OBO:vt.owl (<- this currently points to uPheno, made [ticket](https://github.com/AnimalGenome/vertebrate-trait-ontology/issues/3) to change that)
         1. upheno internal:
            1. OBO:upheno/imports/uberon_import.owl
            1. OBO:upheno/mammal.owl
               1. OBO:mp.owl
               1. OBO:hp.owl
               1. upheno internal:
                  1. OBO:upheno/hp-mp/mp_hp-align-equiv.owl (REMOVED)
                  1. OBO:upheno/upheno_root_alignments.owl (covered, root terms under uPheno:"Phenotype")
                  1. OBO:upheno/imports/go_phenotype.owl (TODO)
                  1. OBO:upheno/imports/mpath_phenotype.owl (TODO)
                  1. OBO:upheno/imports/nbo_phenotype.owl (TODO)
                  1. OBO:upheno/imports/uberon_phenotype.owl (TODO)


text:
# About uPheno

The uPheno project aims to unify the annotation of phenotypes across species in a manner analogous to unification of gene function annotation by the Gene Ontology.
uPheno 2.0 builds on [earlier efforts](https://f1000research.com/articles/2-30/v2) with a strategy that directly leverages the work of the phenotype ontology development community and incorporates phenotypes from a much wider range of species.
We have organised a collaborative community effort, including representatives of all major model organism databases, to document and align formal design patterns for representing phenotypes and further develop reference ontologies, such as PATO, which are used in these patterns.
A common development infrastructure makes it easy to use these design patterns to generate both species-specific ontologies and a species-independent layer that subsumes them.
The resulting community-curated ontology for the representation and integration of phenotypes across species serves two general purposes:
- Providing a community-developed framework for ontology editors to bootstrap, maintain and extend their phenotype ontologies in a scalable and standardised manner.
- Facilitating the retrieval and comparative analysis of species-specific phenotypes through a deep layer of species-independent phenotypes.

Currently, the development of uPheno is organized by a group that meets biweekly. See the [meetings page](/upheno/organization/meetings/) for more info, including how to participate.


text:
# How to cite uPheno

## Papers
### uPheno 2
* Matentzoglu N, Osumi-Sutherland D, Balhoff JP, Bello S, Bradford Y, Cardmody L, Grove C, Harris MA, Harris N, Köhler S, McMurry J, Mungall C, Munoz-Torres M, Pilgrim C, Robb S, Robinson PN, Segerdell E, Vasilevsky N, Haendel M. uPheno 2: Framework for standardised representation of phenotypes across species. 2019 Apr 8. [http://dx.doi.org/10.7490/f1000research.1116540.1](http://dx.doi.org/10.7490/f1000research.1116540.1)

### Original uPheno
* Sebastian Köhler, Sandra C Doelken, Barbara J Ruef, Sebastian Bauer, Nicole Washington, Monte Westerfield, George Gkoutos, Paul Schofield, Damian Smedley, Suzanna E Lewis, Peter N Robinson, Christopher J Mungall (2013) [Construction and accessibility of a cross-species phenotype ontology along with gene annotations for biomedical research](https://f1000research.com/articles/2-30/v2) F1000Research

### Entity-Quality definitions and phenotype modelling
* C J Mungall, Georgios Gkoutos, Cynthia Smith, Melissa Haendel, Suzanna Lewis, Michael Ashburner (2010) [Integrating phenotype ontologies across multiple species](http://genomebiology.com/2010/11/1/R2) Genome Biology 11 (1)


text:
# UPHENO Ontology Documentation

Welcome to the UPHENO documentation!

It is entirely empty at the moment so look no further!

You can find descriptions of the standard ontology engineering workflows [here](odk-workflows/index.md).


text: # How to contribute to UPHENO


text:
# Repository structure

The main kinds of files in the repository:

1. Release files
2. Imports
3. [Components](#Components)

## Release files
Release file are the file that are considered part of the official ontology release and to be used by the community. A detailed descripts of the release artefacts can be found [here](https://github.com/INCATools/ontology-development-kit/blob/master/docs/ReleaseArtefacts.md).

## Imports
Imports are subsets of external ontologies that contain terms and axioms you would like to re-use in your ontology. These are considered "external", like dependencies in software development, and are not included in your "base" product, which is the [release artefact](https://github.com/INCATools/ontology-development-kit/blob/master/docs/ReleaseArtefacts.md) which contains only those axioms that you personally maintain.

These are the current imports in UPHENO

| Import | URL | Type |
| ------ | --- | ---- |
| nbo | http://purl.obolibrary.org/obo/nbo.owl | None |
| pr | http://purl.obolibrary.org/obo/pr.owl | None |
| go | http://purl.obolibrary.org/obo/go.owl | None |
| uberon | http://purl.obolibrary.org/obo/uberon.owl | None |
| ro | http://purl.obolibrary.org/obo/ro.owl | None |
| chebi | http://purl.obolibrary.org/obo/chebi.owl | None |
| hsapdv | http://purl.obolibrary.org/obo/hsapdv.owl | None |
| pato | http://purl.obolibrary.org/obo/pato.owl | None |
| cl | http://purl.obolibrary.org/obo/cl.owl | None |
| mpath | http://purl.obolibrary.org/obo/mpath.owl | None |

## Components
Components, in contrast to imports, are considered full members of the ontology. This means that any axiom in a component is also included in the ontology base - which means it is considered _native_ to the ontology. While this sounds complicated, consider this: conceptually, no component should be part of more than one ontology. If that seems to be the case, we are most likely talking about an import. Components are often not needed for ontologies, but there are some use cases:

1. There is an automated process that generates and re-generates a part of the ontology
2. A part of the ontology is managed in ROBOT templates
3. The expressivity of the component is higher than the format of the edit file. For example, people still choose to manage their ontology in OBO format (they should not) missing out on a lot of owl features. They may chose to manage logic that is beyond OBO in a specific OWL component.


text:
# Updating the Documentation

The documentation for UPHENO is managed in two places (relative to the repository root):

1. The `docs` directory contains all the files that pertain to the content of the documentation (more below)
2. the `mkdocs.yaml` file cotains the documentation config, in particular its navigation bar and theme.

The documentation is hosted using github pages, on a special branch of the repository (called `gh-pages`). It is important that this branch is never deleted - it contains all the files GitHub pages needs to render and deploy the site. It is also important to note that _the gh-pages branch should never be edited manually_. All changes to the docs happen inside the `docs` directory on the `main` branch.

## Editing the docs

### Changing content
All the documentation is contained in the `docs` directory, and is managed in _Markdown_. Markdown is a very simple and convenient way to produce text documents with formatting instructions, and is very easy to learn - it is also used, for example, in GitHub issues. This is a normal editing workflow:

1. Open the `.md` file you want to change in an editor of choice (a simple text editor is often best). _IMPORTANT_: Do not edit any files in the `docs/odk-workflows/` directory. These files are managed by the ODK system and will be overwritten when the repository is upgraded! If you wish to change these files, make an issue on the [ODK issue tracker](https://github.com/INCATools/ontology-development-kit/issues).
2. Perform the edit and save the file
3. Commit the file to a branch, and create a pull request as usual.
4. If your development team likes your changes, merge the docs into master branch.
5. Deploy the documentation (see below)

## Deploy the documentation

The documentation is _not_ automatically updated from the Markdown, and needs to be deployed deliberately. To do this, perform the following steps:

1. In your terminal, navigate to the edit directory of your ontology, e.g.:
   ```
   cd upheno/src/ontology
   ```
2. Now you are ready to build the docs as follows:
   ```
   sh run.sh make update_docs
   ```
   [Mkdocs](https://www.mkdocs.org/) now sets off to build the site from the markdown pages. You will be asked to
    - Enter your username
    - Enter your password (see [here](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) for using GitHub access tokens instead)
      _IMPORTANT_: Using password based authentication will be deprecated this year (2021). Make sure you read up on [personal access tokens](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) if that happens!

   If everything was successful, you will see a message similar to this one:

   ```
   INFO    -  Your documentation should shortly be available at: https://obophenotype.github.io/upheno/
   ```
3. Just to double check, you can now navigate to your documentation pages (usually https://obophenotype.github.io/upheno/).
   Just make sure you give GitHub 2-5 minutes to build the pages!


text:
# Introduction to Continuous Integration Workflows with ODK

Historically, most repos have been using Travis CI for continuous integration testing and building, but due to
runtime restrictions, we recently switched a lot of our repos to GitHub actions. You can set up your repo with CI by adding
this to your configuration file (src/ontology/upheno-odk.yaml):

```
ci:
  - github_actions
```

When [updateing your repo](RepoManagement.md), you will notice a new file being added: `.github/workflows/qc.yml`.

This file contains your CI logic, so if you need to change, or add anything, this is the place!


text:
# Editors Workflow

The editors workflow is one of the formal [workflows](index.md) to ensure that the ontology is developed correctly according to ontology engineering principles. There are a few different editors workflows:

1. Local editing workflow: Editing the ontology in your local environment by hand, using tools such as Protégé, ROBOT templates or DOSDP patterns.
2. Completely automated data pipeline (GitHub Actions)
3. DROID workflow

This document only covers the first editing workflow, but more will be added in the future

### Local editing workflow

Workflow requirements:
- git
- github
- docker
- editing tool of choice, e.g. Protégé, your favourite text editor, etc

#### 1. _Create issue_
Ensure that there is a ticket on your issue tracker that describes the change you are about to make. While this seems optional, this is a very important part of the social contract of building an ontology - no change to the ontology should be performed without a good ticket, describing the motivation and nature of the intended change.

#### 2. _Update main branch_
In your local environment (e.g. your laptop), make sure you are on the `main` (prev. `master`) branch and ensure that you have all the upstream changes, for example:

```
git checkout master
git pull
```

#### 3. _Create feature branch_
Create a new branch. Per convention, we try to use meaningful branch names such as:
- issue23removeprocess (where issue 23 is the related issue on GitHub)
- issue26addcontributor
- release20210101 (for releases)

On your command line, this looks like this:

```
git checkout -b issue23removeprocess
```

#### 4. _Perform edit_
Using your editor of choice, perform the intended edit. For example:

_Protege_

1. Open `src/ontology/upheno-edit.owl` in Protege
2. Make the change
3. Save the file

_TextEdit_

1. Open `src/ontology/upheno-edit.owl` in TextEdit (or Sublime, Atom, Vim, Nano)
2. Make the change
3. Save the file

Consider the following when making the edit.

1. According to our development philosophy, the only places that should be manually edited are:
    - `src/ontology/upheno-edit.owl`
    - Any ROBOT templates you chose to use (the TSV files only)
    - Any DOSDP data tables you chose to use (the TSV files, and potentially the associated patterns)
    - components (anything in `src/ontology/components`), see [here](RepositoryFileStructure.md).
2. Imports should not be edited (any edits will be flushed out with the next update). However, refreshing imports is a potentially breaking change - and is discussed [elsewhere](UpdateImports.md).
3. Changes should usually be small. Adding or changing 1 term is great. Adding or changing 10 related terms is ok. Adding or changing 100 or more terms at once should be considered very carefully.

#### 4. _Check the Git diff_
This step is very important. Rather than simply trusting your change had the intended effect, we should always use a git diff as a first pass for sanity checking.

In our experience, having a visual git client like [GitHub Desktop](https://desktop.github.com/) or [sourcetree](https://www.sourcetreeapp.com/) is really helpful for this part. In case you prefer the command line:

```
git status
git diff
```
#### 5. Quality control
Now its time to run your quality control checks. This can either happen locally ([5a](#Local-testing)) or through your continuous integration system ([7/5b](#continuous-integration-testing)).

#### 5a. Local testing
If you chose to run your test locally:

```
sh run.sh make IMP=false test
```
This will run the whole set of configured ODK tests on including your change. If you have a complex DOSDP pattern pipeline you may want to add `PAT=false` to skip the potentially lengthy process of rebuilding the patterns.

```
sh run.sh make IMP=false PAT=false test
```

#### 6. Pull request

When you are happy with the changes, you commit your changes to your feature branch, push them upstream (to GitHub) and create a pull request. For example:

```
git add NAMEOFCHANGEDFILES
git commit -m "Added biological process term #12"
git push -u origin issue23removeprocess
```

Then you go to your project on GitHub, and create a new pull request from the branch, for example: https://github.com/INCATools/ontology-development-kit/pulls

There is a lot of great advise on how to write pull requests, but at the very least you should:
- mention the tickets affected: `see #23` to link to a related ticket, or `fixes #23` if, by merging this pull request, the ticket is fixed. Tickets in the latter case will be closed automatically by Github when the pull request is merged.
- summarise the changes in a few sentences. Consider the reviewer: what would they want to know right away.
- If the diff is large, provide instructions on how to review the pull request best (sometimes, there are many changed files, but only one important change).

#### 7/5b. Continuous Integration Testing
If you didn't run and local quality control checks (see [5a](#Local-testing)), you should have Continuous Integration (CI) set up, for example:
- Travis
- GitHub Actions

More on how to set this up [here](ContinuousIntegration.md). Once the pull request is created, the CI will automatically trigger. If all is fine, it will show up green, otherwise red.

#### 8. Community review
Once all the automatic tests have passed, it is important to put a second set of eyes on the pull request. Ontologies are inherently social - as in that they represent some kind of community consensus on how a domain is organised conceptually. This seems high brow talk, but it is very important that as an ontology editor, you have your work validated by the community you are trying to serve (e.g. your colleagues, other contributors etc). In our experience, it is hard to get more than one review on a pull request - two is great. You can set up GitHub branch protection to actually require a review before a pull request can be merged! We recommend this.

This step seems daunting to some hopefully under-resourced ontologies, but we recommend to put this high up on your list of priorities - train a colleague, reach out!

#### 9. Merge and cleanup
When the QC is green and the reviews are in (approvals), it is time to merge the pull request. After the pull request is merged, remember to delete the branch as well (this option will show up as a big button right after you have merged the pull request). If you have not done so, close all the associated tickets fixed by the pull request.

#### 10. Changelog (Optional)
It is sometimes difficult to keep track of changes made to an ontology. Some ontology teams opt to document changes in a changelog (simply a text file in your repository) so that when release day comes, you know everything you have changed. This is advisable at least for major changes (such as a new release system, a new pattern or template etc).


text:
# Managing your ODK repository

## Updating your ODK repository

Your ODK repositories configuration is managed in `src/ontology/upheno-odk.yaml`. Once you have made your changes, you can run the following to apply your changes to the repository:

```
sh run.sh make update_repo
```

There are a large number of options that can be set to configure your ODK, but we will only discuss a few of them here.

## Managing imports

You can use the update repository worflow described on this page to perform the following operations to your imports:

1. Add a new import
2. Modify an existing import
3. Remove an import you no longer want
4. Customise an import

We will discuss all these workflows in the following.

### Add new import

To add a new import, you first edit your odk config as described [above](#Updating-your-ODK-repository), adding an `id` to the `product` list in the `import_group` section (for the sake of this example, we assume you already import RO, and your goal is to also import GO):

```
import_group:
  products:
    - id: ro
    - id: go
```

Note: our ODK file should only have one `import_group` which can contain multiple imports (in the `products` section). Next, you run the [update repo workflow](#Updating-your-ODK-repository) to apply these changes. Note that by default, this module is going to be a SLME Bottom module, see [here](http://robot.obolibrary.org/extract). To change that or customise your module, see section "Customise an import". To finalise the addition of your import, perform the following steps:

1. Add an imports statement to your `src/ontology/upheno-edit.owl` file. We suggest to do this using a text editor, by simply copying an existing imports declaration and renaming it to the new ontology import, for example as follows:

```
...
Ontology(<http://purl.obolibrary.org/obo/upheno.owl>
Import(<http://purl.obolibrary.org/obo/upheno/imports/ro_import.owl>)
Import(<http://purl.obolibrary.org/obo/upheno/imports/go_import.owl>)
...
```

2. Add your imports redirect to your catalog file `src/ontology/catalog-v001.xml`, for example:

```
<uri name="http://purl.obolibrary.org/obo/upheno/imports/go_import.owl" uri="imports/go_import.owl"/>
```

3. Test whether everything is in order:
    1. [Refresh your import](UpdateImports.md)
    2. Open in your Ontology Editor of choice (Protege) and ensure that the expected terms are imported.

### Modify an existing import

If you simply wish to refresh your import in light of new terms, see [here](UpdateImports.md). If you wish to change the type of your module see section "Customise an import".

### Remove an existing import

To remove an existing import, perform the following steps:

1. remove the import declaration from your `src/ontology/upheno-edit.owl`.
2. remove the id from your `src/ontology/upheno-odk.yaml`, eg. `- id: go` from the list of `products` in the `import_group`.
3. run [update repo workflow](#Updating-your-ODK-repository)
4. delete the associated files manually:
    - `src/imports/go_import.owl`
    - `src/imports/go_terms.txt`
5. Remove the respective entry from the `src/ontology/catalog-v001.xml` file.

### Customise an import

By default, an import module extracted from a source ontology will be a SLME module, see [here](http://robot.obolibrary.org/extract). There are various options to change the default.

The following change to your repo config (`src/ontology/upheno-odk.yaml`) will switch the go import from an SLME module to a simple ROBOT filter module:

```
import_group:
  products:
    - id: ro
    - id: go
      module_type: filter
```

A ROBOT filter module is, essentially, importing all external terms declared by the your ontology (see [here](UpdateImports.md)] on how to declare external terms to be imported). Note that the `filter` module does
not consider terms/annotations from namespaces other than the base-namespace of the ontology itself. For example, in the
example of GO above, only annotations / axioms related to the GO base IRI (http://purl.obolibrary.org/obo/GO_) would be considered. This
behaviour can be changed by adding additional base IRIs as follows:

```
import_group:
  products:
    - id: go
      module_type: filter
      base_iris:
        - http://purl.obolibrary.org/obo/GO_
        - http://purl.obolibrary.org/obo/CL_
        - http://purl.obolibrary.org/obo/BFO
```

If you wish to customise your import entirely, you can specify your own ROBOT command to do so. To do that, add the following to your repo config (`src/ontology/upheno-odk.yaml`):

```
import_group:
  products:
    - id: ro
    - id: go
      module_type: custom
```

Now add a new goal in your custom Makefile (`src/ontology/upheno.Makefile`, _not_ `src/ontology/Makefile`).

```
imports/go_import.owl: mirror/ro.owl imports/ro_terms_combined.txt
	if [ $(IMP) = true ]; then $(ROBOT) query  -i $< --update ../sparql/preprocess-module.ru \
		extract -T imports/ro_terms_combined.txt --force true --individuals exclude --method BOT \
		query --update ../sparql/inject-subset-declaration.ru --update ../sparql/postprocess-module.ru \
		annotate --ontology-iri $(ONTBASE)/$@ $(ANNOTATE_ONTOLOGY_VERSION) --output $@.tmp.owl && mv $@.tmp.owl $@; fi
```

Now feel free to change this goal to do whatever you wish it to do! It probably makes some sense (albeit not being a strict necessity), to leave most of the goal instead and replace only:

```
extract -T imports/ro_terms_combined.txt --force true --individuals exclude --method BOT \
```

to another ROBOT pipeline.

_Note_: if your mirror is particularly large and complex, read [this ODK recommendation](https://github.com/INCATools/ontology-development-kit/blob/master/docs/DealWithLargeOntologies.md).


text:
# Setting up your Docker environment for ODK use

One of the most frequent problems with running the ODK for the first time is failure because of lack of memory. This can look like a Java OutOfMemory exception,
but more often than not it will appear as something like an `Error 137`. There are two places you need to consider to set your memory:

1. Your src/ontology/run.sh (or run.bat) file. You can set the memory in there by adding
`robot_java_args: '-Xmx8G'` to your src/ontology/upheno-odk.yaml file, see for example [here](https://github.com/INCATools/ontology-development-kit/blob/0e0aef2b26b8db05f5e78b7c38f807d04312d06a/configs/uberon-odk.yaml#L36).
2. Set your docker memory. By default, it should be about 10-20% more than your `robot_java_args` variable. You can manage your memory settings
by right-clicking on the docker whale in your system bar-->Preferences-->Resources-->Advanced, see picture below.

![dockermemory](https://github.com/INCATools/ontology-development-kit/raw/master/docs/img/docker_memory.png)


text:
# Update Imports Workflow

This page discusses how to update the contents of your imports, like adding or removing terms. If you are looking to customise imports, like changing the module type, see [here](RepoManagement.md).

## Importing a new term

Note: some ontologies now use a merged-import system to manage dynamic imports, for these please follow instructions in the section title "Using the Base Module approach".

Importing a new term is split into two sub-phases:

1. Declaring the terms to be imported
2. Refreshing imports dynamically

### Declaring terms to be imported
There are three ways to declare terms that are to be imported from an external ontology. Choose the appropriate one for your particular scenario (all three can be used in parallel if need be):

1. Protege-based declaration
2. Using term files
3. Using the custom import template

#### Protege-based declaration

This workflow is to be avoided, but may be appropriate if the editor _does not have access to the ODK docker container_.
This approach also applies to ontologies that use base module import approach.

1. Open your ontology (edit file) in Protege (5.5+).
1. Select 'owl:Thing'
1. Add a new class as usual.
1. Paste the _full iri_ in the 'Name:' field, for example, http://purl.obolibrary.org/obo/CHEBI_50906.
1. Click 'OK'

<img src="https://raw.githubusercontent.com/INCATools/ontology-development-kit/master/docs/img/AddingClasses.png" alt="Adding Classes" />

Now you can use this term for example to construct logical definitions. The next time the imports are refreshed (see how to refresh [here](#Refresh-imports)), the metadata (labels, definitions, etc) for this term are imported from the respective external source ontology and becomes visible in your ontology.

#### Using term files

Every import has, by default a term file associated with it, which can be found in the imports directory. For example, if you have a GO import in `src/ontology/go_import.owl`, you will also have an associated term file `src/ontology/go_terms.txt`. You can add terms in there simply as a list:

```
GO:0008150
GO:0008151
```

Now you can run the [refresh imports workflow](#Refresh-imports)) and the two terms will be imported.

#### Using the custom import template

This workflow is appropriate if:

1. You prefer to manage all your imported terms in a single file (rather than multiple files like in the "Using term files" workflow above).
2. You wish to augment your imported ontologies with additional information. This requires a cautionary discussion.

To enable this workflow, you add the following to your ODK config file (`src/ontology/upheno-odk.yaml`), and [update the repository](RepoManagement.md):

```
use_custom_import_module: TRUE
```

Now you can manage your imported terms directly in the custom external terms template, which is located at `src/templates/external_import.owl`. Note that this file is a [ROBOT template](http://robot.obolibrary.org/template), and can, in principle, be extended to include any axioms you like. Before extending the template, however, read the following carefully.

The main purpose of the custom import template is to enable the management off all terms to be imported in a centralised place. To enable that, you do not have to do anything other than maintaining the template. So if you, say current import `APOLLO_SV:00000480`, and you wish to import `APOLLO_SV:00000532`, you simply add a row like this:

```
ID	Entity Type
ID	TYPE
APOLLO_SV:00000480	owl:Class
APOLLO_SV:00000532	owl:Class
```

When the imports are refreshed [see imports refresh workflow](#Refresh-imports), the term(s) will simply be imported from the configured ontologies.

Now, if you wish to extent the Makefile (which is beyond these instructions) and add, say, synonyms to the imported terms, you can do that, but you need to (a) preserve the `ID` and `ENTITY` columns and (b) ensure that the ROBOT template is valid otherwise, [see here](http://robot.obolibrary.org/template).

_WARNING_. Note that doing this is a _widespread antipattern_ (see related [issue](https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443)). You should not change the axioms of terms that do not belong into your ontology unless necessary - such changes should always be pushed into the ontology where they belong. However, since people are doing it, whether the OBO Foundry likes it or not, at least using the _custom imports module_ as described here localises the changes to a single simple template and ensures that none of the annotations added this way are merged into the [base file](https://github.com/INCATools/ontology-development-kit/blob/master/docs/ReleaseArtefacts.md#release-artefact-1-base-required).

### Refresh imports

If you want to refresh the import yourself (this may be necessary to pass the travis tests), and you have the ODK installed, you can do the following (using go as an example):

First, you navigate in your terminal to the ontology directory (underneath src in your hpo root directory).
```
cd src/ontology
```

Then, you regenerate the import that will now include any new terms you have added. Note: You must have [docker installed](SettingUpDockerForODK.md).

```
sh run.sh make PAT=false imports/go_import.owl -B
```

Since ODK 1.2.27, it is also possible to simply run the following, which is the same as the above:

```
sh run.sh make refresh-go
```

Note that in case you changed the defaults, you need to add `IMP=true` and/or `MIR=true` to the command below:

```
sh run.sh make IMP=true MIR=true PAT=false imports/go_import.owl -B
```

If you wish to skip refreshing the mirror, i.e. skip downloading the latest version of the source ontology for your import (e.g. `go.owl` for your go import) you can set `MIR=false` instead, which will do the exact same thing as the above, but is easier to remember:

```
sh run.sh make IMP=true MIR=false PAT=false imports/go_import.owl -B
```

## Using the Base Module approach

Since ODK 1.2.31, we support an entirely new approach to generate modules: Using base files.
The idea is to only import axioms from ontologies that _actually belong to it_.
A base file is a subset of the ontology that only contains those axioms that nominally
belong there. In other words, the base file does not contain any axioms that belong
to another ontology. An example would be this:

Imagine this being the full Uberon ontology:

```
Axiom 1: BFO:123 SubClassOf BFO:124
Axiom 1: UBERON:123 SubClassOf BFO:123
Axiom 1: UBERON:124 SubClassOf UBERON 123
```

The base file is the set of all axioms that are about UBERON terms:

```
Axiom 1: UBERON:123 SubClassOf BFO:123
Axiom 1: UBERON:124 SubClassOf UBERON 123
```

I.e.

```
Axiom 1: BFO:123 SubClassOf BFO:124
```

Gets removed.

The base file pipeline is a bit more complex then the normal pipelines, because
of the logical interactions between the imported ontologies. This is solved by _first
merging all mirrors into one huge file and then extracting one mega module from it.

Example: Let's say we are importing terms from Uberon, GO and RO in our ontologies.
When we use the base pipelines, we

1) First obtain the base (ususally by simply downloading it, but there is also an option now to create it with ROBOT)
2) We merge all base files into one big pile
3) Then we extract a single module `imports/merged_import.owl`

The first implementation of this pipeline is PATO, see https://github.com/pato-ontology/pato/blob/master/src/ontology/pato-odk.yaml.

To check if your ontology uses this method, check src/ontology/upheno-odk.yaml to see if `use_base_merging: TRUE` is declared under `import_group`

If your ontology uses Base Module approach, please use the following steps:

First, add the term to be imported to the term file associated with it (see above "Using term files" section if this is not clear to you)

Next, you navigate in your terminal to the ontology directory (underneath src in your hpo root directory).
```
cd src/ontology
```

Then refresh imports by running

```
sh run.sh make imports/merged_import.owl
```
Note: if your mirrors are updated, you can run `sh run.sh make no-mirror-refresh-merged`

This requires quite a bit of memory on your local machine, so if you encounter an error, it might be a lack of memory on your computer. A solution would be to create a ticket in an issue tracker requesting for the term to be imported, and your one of the local devs should pick this up and run the import for you.

Lastly, restart Protege, and the term should be imported in ready to be used.


text:
# Default ODK Workflows

- [Daily Editors Workflow](EditorsWorkflow.md)
- [Release Workflow](ReleaseWorkflow.md)
- [Manage your ODK Repository](RepoManagement.md)
- [Setting up Docker for ODK](SettingUpDockerForODK.md)
- [Imports management](UpdateImports.md)
- [Managing the documentation](ManageDocumentation.md)


text:
# The release workflow
The release workflow recommended by the ODK is based on GitHub releases and works as follows:

1. Run a release with the ODK
2. Review the release
3. Merge to main branch
4. Create a GitHub release

These steps are outlined in detail in the following.

## Run a release with the ODK

Preparation:

1. Ensure that all your pull requests are merged into your main (master) branch
2. Make sure that all changes to master are committed to Github (`git status` should say that there are no modified files)
3. Locally make sure you have the latest changes from master (`git pull`)
4. Checkout a new branch (e.g. `git checkout -b release-2021-01-01`)
5. You may or may not want to refresh your imports as part of your release strategy (see [here](UpdateImports.md))
6. Make sure you have the latest ODK installed by running `docker pull obolibrary/odkfull`

To actually run the release, you:

1. Open a command line terminal window and navigate to the src/ontology directory (`cd upheno/src/ontology`)
2. Run release pipeline:`sh run.sh make prepare_release -B`. Note that for some ontologies, this process can take up to 90 minutes - especially if there are large ontologies you depend on, like PRO or CHEBI.
3. If everything went well, you should see the following output on your machine: `Release files are now in ../.. - now you should commit, push and make a release on your git hosting site such as GitHub or GitLab`.

This will create all the specified release targets (OBO, OWL, JSON, and the variants, ont-full and ont-base) and copy them into your release directory (the top level of your repo).

## Review the release

1. (Optional) Rough check. This step is frequently skipped, but for the more paranoid among us (like the author of this doc), this is a 3 minute additional effort for some peace of mind. Open the main release (upheno.owl) in you favourite development environment (i.e. Protege) and eyeball the hierarchy. We recommend two simple checks:
    1. Does the very top level of the hierarchy look ok? This means that all new terms have been imported/updated correctly.
    2. Does at least one change that you know should be in this release appear? For example, a new class. This means that the release was actually based on the recent edit file.
2. Commit your changes to the branch and make a pull request
3. In your GitHub pull request, review the following three files in detail (based on our experience):
    1. `upheno.obo` - this reflects a useful subset of the whole ontology (everything that can be covered by OBO format). OBO format has that speaking for it: it is very easy to review!
    2. `upheno-base.owl` - this reflects the asserted axioms in your ontology that you have actually edited.
    3. Ideally also take a look at `upheno-full.owl`, which may reveal interesting new inferences you did not know about. Note that the diff of this file is sometimes quite large.
4. Like with every pull request, we recommend to always employ a second set of eyes when reviewing a PR!

## Merge the main branch
Once your [CI checks](ContinuousIntegration.md) have passed, and your reviews are completed, you can now merge the branch into your main branch (don't forget to delete the branch afterwards - a big button will appear after the merge is finished).

## Create a GitHub release

1. Go to your releases page on GitHub by navigating to your repository, and then clicking on releases (usually on the right, for example: https://github.com/obophenotype/upheno/releases. Then click "Draft new release"
1. As the tag version you **need to choose the date on which your ontologies were build.** You can find this, for example, by looking at the `upheno.obo` file and check the `data-version:` property. The date needs to be prefixed with a `v`, so, for example `v2020-02-06`.
1. You can write whatever you want in the release title, but we typically write the date again. The description underneath should contain a concise list of changes or term additions.
1. Click "Publish release". Done.

## Debugging typical ontology release problems

### Problems with memory

When you are dealing with large ontologies, you need a lot of memory. When you see error messages relating to large ontologies such as CHEBI, PRO, NCBITAXON, or Uberon, you should think of memory first, see [here](https://github.com/INCATools/ontology-development-kit/blob/master/docs/DealWithLargeOntologies.md).

### Problems when using OBO format based tools

Sometimes you will get cryptic error messages when using legacy tools using OBO format, such as the ontology release tool (OORT), which is also available as part of the ODK docker container. In these cases, you need to track down what axiom or annotation actually caused the breakdown. In our experience (in about 60% of the cases) the problem lies with duplicate annotations (`def`, `comment`) which are illegal in OBO. Here is an example recipe of how to deal with such a problem:

1. If you get a message like `make: *** [cl.Makefile:84: oort] Error 255` you might have a OORT error.
2. To debug this, in your terminal enter `sh run.sh make IMP=false PAT=false oort -B` (assuming you are already in the ontology folder in your directory)
3. This should show you where the error is in the log (eg multiple different definitions)
WARNING: THE FIX BELOW IS NOT IDEAL, YOU SHOULD ALWAYS TRY TO FIX UPSTREAM IF POSSIBLE
4. Open `upheno-edit.owl` in Protege and find the offending term and delete all offending issue (e.g. delete ALL definition, if the problem was "multiple def tags not allowed") and save.
*While this is not idea, as it will remove all definitions from that term, it will be added back again when the term is fixed in the ontology it was imported from and added back in.
5. Rerun `sh run.sh make IMP=false PAT=false oort -B` and if it all passes, commit your changes to a branch and make a pull request as usual.


text:
# Pattern merge - replace workflow

This document is on how to merge new DOSDP design patterns into an ODK ontology and then how to replace the old classes with the new ones.

### 1. You need the tables in tsv format with the DOSDP filler data. Download the tsv tables to

    $ODK-ONTOLOGY/src/patterns/data/default/

Make sure that the tsv filenames match that of the relevant yaml DOSDP pattern files.

### 2. Add the new matching pattern yaml filename to

    $ODK-ONTOLOGY/src/patterns/dosdp-patterns/external.txt

### 3. Import the new pattern templates that you have just added to the `external.txt` list from external sources into the current working repository

    cd ODK-ONTOLOGY/src/ontology
    sh run.sh make update_patterns

### 4. make definitions.owl

    cd ODK-ONTOLOGY/src/ontology
    sh run.sh make ../patterns/definitions.owl IMP=false

### 5. Remove old classes and replace them with the equivalent and patternised new classes

    cd ODK-ONTOLOGY/src/ontology
    sh run.sh make remove_patternised_classes

### 6. Announce the pattern migration in an appropriate channel, for example on the phenotype-ontologies Slack channel.

For example:

>
I have migrated the ... table and changed the tab colour to blue.
You can delete the tab if you wish.


text:
# How to set yourself up for S3

To be able to upload new uPheno release to the uPheno S3 bucket, you need to set yourself up for S3 first.

1. [Download and install AWS CLI](#Download and install aws CLI)
2. [Obtain secrets from BBOP](#Obtain secrets from BBOP)
3. [Add configuration for secrets](#Add configuration for secrets)

# 1. Download and install AWS CLI

The most convenient way to interact with S3 is the [AWS Command Line Interface (CLI)](https://aws.amazon.com/cli/). You can find the installers and install instructions on that page (different depending on your Operation System):
- For [Mac](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-mac.html)
- For [Windows](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html)

# 2. Obtain secrets from BBOP

Next, you need to ask someone at BBOP (such as Chris Mungall or Seth Carbon) to provide you with an account that gives you access to the BBOP s3 buckets. You will have to provide a username. You will receive:
- User name
- Access key ID-
- Secret access key
- Console link to sign into bucket

# 3. Add configuration for secrets

You will now have to set up your local system. You will create two files:

```
$ less ~/.aws/config
[default]
region = us-east-1
```

and

```
$ less ~/.aws/credentials
[default]
aws_access_key_id = ***
aws_secret_access_key = ***
```

in `~/.aws/credentials` make sure you add the correct keys as provided above.

# 4. Write to your bucket

Now, you should be set up to write to your s3 bucket. Note that in order for your data to be accessible through `https` after your upload, you need to add `--acl public read`.

```
aws s3 sync --exclude "*.DS_Store*" my/data-dir s3://bbop-ontologies/myproject/data-dir --acl public-read
```

If you have previously pushed data to the same location, you wont be able to set it to "publicly readable" by simply rerunning the sync command. If you want to publish previously private data, follow the instructions [here](https://aws.amazon.com/premiumsupport/knowledge-center/read-access-objects-s3-bucket/), e.g.:

```
aws s3api put-object-acl --bucket s3://bbop-ontologies/myproject/data-dir --key exampleobject --acl public-read
```


text:
# How to run a uPheno 2 release

In order to run a release you will have to have completed the steps to [set up s3](set-up-s3.md).

1. Clone https://github.com/obophenotype/upheno-dev
2. `cd src/scripts`
3. `sh upheno_pipeline.sh`
4. `cd ../ontology`
5. `make prepare_upload S3_VERSION=2022-06-19`
6. `make deploy S3_VERSION=2022-06-19`


text:
# Add custom uPheno Makefile

The custom uPheno Makefile is an extension to your normal custom Makefile (for example, hp.Makefile, mp.Makefile, etc), located in the src/ontology directory of your ODK set up.

To install it:

(1) Open your normal custom Makefile and add a line in the very end:

```
include pheno.Makefile
```

(2) Now download the custom Makefile:

https://raw.githubusercontent.com/obophenotype/upheno/master/src/ontology/config/pheno.Makefile

and save it in your `src/ontology` directory.

Feel free to use, for example, wget:

```
cd src/ontology
wget https://raw.githubusercontent.com/obophenotype/upheno/master/src/ontology/config/pheno.Makefile -O pheno.Makefile
```

From now on you can simply run

```
sh run.sh make update_pheno_makefile
```

whenever you wish to synchronise the Makefile with the uPheno repo.

(Note: it would probably be good to add a GitHub action that does that automatically.)


text:
# Phenotype Ontology Editors' Workflow

### Useful links
* [Phenotype Ontology Working Group Meetings agenda and minutes gdoc](https://docs.google.com/document/d/1WrQanAMuccS-oaoAIb9yWQAd4Rvy3R3mU01v9wHbriM/).
* [phenotype-ontologies slack channel](https://phenotype-ontologies.slack.com/archives/CCWEMEJM8/p1685549784709229): to send meeting reminders; ask for agenda items; questions; discussions *etc.*
* Dead simple owl design pattern (DOS-DP) [Documentation](https://incatools.github.io/dead_simple_owl_design_patterns/)
    * [Getting started with DOSDP templates](https://oboacademy.github.io/obook/tutorial/dosdp-overview/).
    * [Dead Simple Ontology Design Patterns (DOSDP)](https://oboacademy.github.io/obook/tutorial/dosdp-template/).
    * [Using DOSDP templates in ODK Workflows](https://oboacademy.github.io/obook/tutorial/dosdp-odk/).
* Validate DOS-DP yaml templates:
    1. [yamllint](https://yamllint.readthedocs.io/en/stable/): yaml syntax validator
        * [Installing yamllint](https://formulae.brew.sh/formula/yamllint): `brew install yamllint`
    * Congiguring yamllint
        You can ignore the `error line too long` yaml syntax errors for dos-dp yaml templates.
        You can create a custom configuration file for yamllint in your home folder:
        ```sh
        touch ~/.config/yamllint/config
        ```
        The content of the config file should look like this:
        ```yaml
        # Custom configuration file for yamllint
        # It extends the default conf by adjusting some options.

        extends: default

        rules:
          line-length:
            max: 80 # 80 chars should be enough, but don't fail if a line is longer
        #   max: 140  # allow long lines
            level: warning
            allow-non-breakable-words: true
            allow-non-breakable-inline-mappings: true
        ```
        The custom config should turn the `error line too long` errors to warnings.
    2. [DOS-DP validator:](https://incatools.github.io/dead_simple_owl_design_patterns/validator/): DOS-DP format validator
        * [Installing ](https://github.com/INCATools/dead_simple_owl_design_patterns): `pip install dosdp`

Patternisation is the process of ensuring that all entity quality (EQ) descriptions from textual phenotype term definitions have a logical definition pattern. A pattern is a standard format for describing a phenotype that includes a quality and an entity. For example, "increased body size" is a pattern that includes the quality "increased" and the entity "body size." The goal of patternisation is to make the EQ descriptions more uniform and machine-readable, which facilitates downstream analysis.

## 1. Identify a group of related phenotypes from diverse organisms

The first step in the Phenotype Ontology Editors' Workflow is to identify a group of related phenotypes from diverse organisms. This can be done by considering proposals from phenotype editors or by using the pattern suggestion pipeline.
The phenotype editors may propose a group of related phenotypes based on their domain knowledge, while the pattern suggestion pipeline uses semantic similarity and shared [Phenotype And Trait Ontology (PATO)](https://www.ebi.ac.uk/ols4/ontologies/pato) quality terms to identify patterns in phenotype terms from different organism-specific ontologies.

## 2. Propose a phenotype pattern

Once a group of related phenotypes is identified, the editors propose a phenotype pattern. To do this, they create a Github issue to request the phenotype pattern template in the uPheno repository.
Alternatively, a new template can be proposed at a phenotype editors' meeting which can lead to the creation of a new term request as a Github issue.
Ideally, the proposed phenotype pattern should include an appropriate [PATO](https://www.ebi.ac.uk/ols4/ontologies/pato) quality term for logical definition, use cases, term examples, and a textual definition pattern for the phenotype terms.

## 3. Discuss the new phenotype pattern draft at the regular uPheno phenotype editors meeting

The next step is to discuss the new phenotype pattern draft at the regular uPheno phenotype editors meeting. During the meeting, the editors' comments and suggestions for improvements are collected as comments on the DOS-DP `yaml` template in the corresponding Github pull request. Based on the feedback and discussions, a consensus on improvements should be achieved.
The DOS-DP `yaml` template is named should start with a lower case letter, should be informative, and must include the PATO quality term.
A Github pull request is created for the DOS-DP `yaml` template.

* A DOS-DP phenotype pattern template example:

```yaml
---
pattern_name: ??pattern_and_file_name

pattern_iri: http://purl.obolibrary.org/obo/upheno/patterns-dev/??pattern_and_file_name.yaml

description: 'A description that helps people chose this pattern for the appropriate scenario.'

#  examples:
#    - example_IRI-1  # term name
#    - example_IRI-2  # term name
#    - example_IRI-3  # term name
#    - http://purl.obolibrary.org/obo/XXXXXXXXXX  # XXXXXXXX

contributors:
  - https://orcid.org/XXXX-XXXX-XXXX-XXXX  # Yyy Yyyyyyyyy

classes:
  process_quality: PATO:0001236
  abnormal: PATO:0000460
  anatomical_entity: UBERON:0001062

relations:
  characteristic_of: RO:0000052
  has_modifier: RO:0002573
  has_part: BFO:0000051

annotationProperties:
  exact_synonym: oio:hasExactSynonym
  related_synonym: oio:hasRelatedSynonym
  xref: oio:hasDbXref

vars:
  var??: "'anatomical_entity'"  # "'variable_range'"

name:
  text: "trait ?? %s"
  vars:
    - var??

annotations:
  - annotationProperty: exact_synonym
    text: "? of %s"
    vars:
      - var??

  - annotationProperty: related_synonym
    text: "? %s"
    vars:
      - var??

  - annotationProperty: xref
    text: "AUTO:patterns/patterns/chemical_role_attribute"

def:
  text: "A trait that ?? %s."
  vars:
    - var??

equivalentTo:
  text: "'has_part' some (
    'XXXXXXXXXXXXXXXXX' and
    ('characteristic_of' some %s) and
    ('has_modifier' some 'abnormal')
    )"
  vars:
    - var??
...
```

## 4. Review the candidate phenotype pattern

Once a consensus on the improvements for a particular template is achieved, they are incorporated into the DOS-DP `yaml` file. Typically, the improvements are applied to the template some time before a subsequent ontology editor's meeting. There should be enough time for off-line review of the proposed pattern to allow community feedback.
The improved phenotype pattern candidate draft should get approval from the community at one of the regular ontology editors' call or in a Github comment.
The ontology editors who approve the pattern provide their ORCIDs and they are credited as contributors in an appropriate field of the DOS-DP pattern template.

## 5. Add the community-approved phenotype pattern template to uPheno
Once the community-approved phenotype pattern template is created, it is added to the uPheno Github repository.
The approved DOS-DP `yaml` phenotype pattern template should pass quality control (QC) steps.
1. Validate yaml syntax: [yamllint](https://formulae.brew.sh/formula/yamllint)
2. Validate DOS-DP
Use [DOSDP Validator](https://github.com/INCATools/dead_simple_owl_design_patterns/blob/master/docs/validator.md).
* To validate a template using the command line interface, execute:
```sh
yamllint <test.yaml or 'test folder'>
dosdp validate -i <test.yaml or 'test folder'>

After successfully passing QC, the responsible editor merges the approved pull request, and the phenotype pattern becomes part of the uPheno phenotype pattern template collection.


text:
# How to add the uPheno direct relation extension

EQ definitions are powerful tools for reconciling phenotypes across species and driving reasoning. However, they are not all that useful for many "normal" users of our ontologies.

We have developed a little workflow extension to take care of that.

1. As usual please follow the steps to [install the custom uPheno Makefile extension](custom-upheno-makefile.md) first.
1. Now add a new component to your ont-odk.yaml file (e.g. `src/ontology/mp-odk.yaml`):
```
components:
  products:
    - filename: eq-relations.owl
```
1. We can now choose if we want to add the component to your edit file as well. To do that, follow the [instructions on adding an import](../odk-workflows/RepoManagement.md#Add-new-import) (i.e. adding the component to the edit file and catalog file). The IRI of the component is `http://purl.obolibrary.org/obo/YOURONTOLOGY/components/eq-relations.owl`. For example, for MP, the IRI is `http://purl.obolibrary.org/obo/mp/components/eq-relations.owl`.
1. Now we can generate the component:
```
sh run.sh make components/eq-relations.owl
```
This command will be run automatically during a release (`prepare_release`).


text:
1.  labels Featured
2.  Imported ontologies

Introduction
============

Imports directory:

`* `[`http://purl.obolibrary.org/obo/upheno/imports/`](http://purl.obolibrary.org/obo/upheno/imports/)

Currently the imports includes:

`* imports/chebi_import.owl`\
`* imports/doid_import.owl`\
`* imports/go_import.owl`\
`* imports/mpath_import.owl`\
`* imports/pato_import.owl`\
`* imports/pr_import.owl`\
`* imports/uberon_import.owl`\
`* imports/wbbt_import.owl`

Anatomy
=======

To avoid multiple duplicate classes for heart, lung, skin etc we map all
classes to [Uberon] where this is applicable. For more divergent species
such as fly and C elegans we use the appropriate species-specific
ontology.

Currently there are a small number of highly specific classes in FMA
that are being used and have no corresponding class in Uberon

Methods
=======

We use the OWLAPI SyntacticLocalityModularityExtractor, via [OWLTools].
See the <http://purl.obolibrary.org/obo/upheno/Makefile> for details


text:
## IGNORE

Some old notes

This repository contains common files ontologies and workflows shared
between multiple phenotype ontologies.

See (docs/)[docs] for details

For more background, please see:

 * Sebastian Köhler, Sandra C Doelken, Barbara J Ruef, Sebastian Bauer, Nicole Washington, Monte Westerfield, George Gkoutos, Paul Schofield, Damian Smedley, Suzanna E Lewis, Peter N Robinson, Christopher J Mungall (2013) [Construction and accessibility of a cross-species phenotype ontology along with gene annotations for biomedical research](http://f1000research.com/articles/2-30/v1) F1000Research
 * C J Mungall, Georgios Gkoutos, Cynthia Smith, Melissa Haendel, Suzanna Lewis, Michael Ashburner (2010) [Integrating phenotype ontologies across multiple species](http://genomebiology.com/2010/11/1/R2) Genome Biology 11 (1)

Getting Started
===============

Please see [GettingStarted] for details on how to work with the OWL
files

OWL axiomatization
==================

The [OWLAxiomatization] page describes how we represent phenotypes in
OWL, and how we reason with the resulting structures

Applications
============

The [Applications] page describes how the OWL axiomatization is used in
applications such as [OWLSim](http://owlsim.org). This also describes
the [CrossSpeciesPhenotypeOntology].

Diseases
========

The primary focus of this repository is on phenotypes, which we consider
distinct from diseases. However the [DiseaseIntegration] page contains
preliminary information on integrating and axiomatization of disease
ontologies.

Traits
======

See [TraitsAndPhenotypes].

Automated builds and QC
=======================

See the
[build-pheno-ontologies](http://build.berkeleybop.org/job/build-pheno-ontologies)
job on the Berkeley jenkins server


text:
1.  summary Getting started with OWL phenotype axioms

Introduction
============

This page describes how to get started with the OWL axioms

Opening OWL files in Protege
============================

Unfortunately the full OWL axiomatization is not yet visible in OntoBee,
the best way to view these is to look at them in Protege 4.

You can open any of the PURLs directly in Protege. For example

`* `[`http://purl.obolibrary.org/obo/mp/mp-importer.owl`](http://purl.obolibrary.org/obo/mp/mp-importer.owl)` - for [MP]`\
`* `[`http://purl.obolibrary.org/obo/hp/hp-importer.owl`](http://purl.obolibrary.org/obo/hp/hp-importer.owl)` - for [HP]`

Loading over the web can be slow, so you may want to check files out
locally. Click on the link "source" above to see how to check out the
repo using SVN. Once checked out, you should have a directory structure:

`* `[`src`](http://phenotype-ontologies.googlecode.com/svn/trunk/src/)\
` * `[`ontology`](http://phenotype-ontologies.googlecode.com/svn/trunk/src/ontology/)\
`  * `[`mp`](http://phenotype-ontologies.googlecode.com/svn/trunk/src/ontology/mp/)\
`  * `[`hp`](http://phenotype-ontologies.googlecode.com/svn/trunk/src/ontology/hp/)\
`  * ...`

If you open any of the importer files, Protege will be use the catalog
XML to route requests to the local files.

If you are using [OWLTools], you can use the "--use-catalog" option to
load ontologies using the catalog

Multi-species importers
=======================

`* `[`http://purl.obolibrary.org/obo/upheno/mammal.owl`](http://purl.obolibrary.org/obo/upheno/mammal.owl)\
`* `[`http://purl.obolibrary.org/obo/upheno/vertebrate.owl`](http://purl.obolibrary.org/obo/upheno/vertebrate.owl)\
`* `[`http://purl.obolibrary.org/obo/upheno/metazoa.owl`](http://purl.obolibrary.org/obo/upheno/metazoa.owl)\
`* `[`http://purl.obolibrary.org/obo/upheno/eukaryote.owl`](http://purl.obolibrary.org/obo/upheno/eukaryote.owl)

See Also
========

See also [Imports]


text:
1.  summary PATO

Introduction
============

PATO is an ontology of phenotypic qualities. We use PATO to compose
phenotypic descriptions. See [OWLAxiomatization]

Details
=======

See <https://code.google.com/p/pato/>


text:
1.  summary Worm Phenotype Ontology
2.  labels Featured

Links
=====

`* Schindelman, Gary, et al. `[`Worm` `Phenotype` `Ontology:`
`integrating` `phenotype` `data` `within` `and` `beyond` `the` `C.`
`elegans`
`community.`](http://www.biomedcentral.com/1471-2105/12/32/)` BMC bioinformatics 12.1 (2011): 32.`\
`* `[`WBPhenotype` `in`
`OntoBee`](http://www.ontobee.org/browser/index.php?o=WBPhenotype)\
`* `[`WBPhenotype` `in`
`OLSVis`](http://ols.wordvis.com/q=WBPhenotype:0000886)

OWL Axiomatization
==================

The OWL axioms for WBPhenotype are in the
[src/ontology/wbphenotype](http://phenotype-ontologies.googlecode.com/svn/trunk/src/ontology/wbphenotype/)
directory on this site.

`* `[`http://purl.obolibrary.org/obo/wbphenotype.owl`](http://purl.obolibrary.org/obo/wbphenotype.owl)` - direct conversion of WormBase-supplied obo file`\
`* `[`http://purl.obolibrary.org/obo/wbphenotype/wbphenotype-importer.owl`](http://purl.obolibrary.org/obo/wbphenotype/wbphenotype-importer.owl)` - imports additional axioms.`

The structure roughly follows that of the [MP]. The worm anatomy is
used.

Editing the axioms
==================

Currently the source is wbphenotype/wbphenotype-equivalence-axioms.obo,
the OWL is generated from here. We are considering switching this
around, so the OWL is edited, using Protege.


text:
1.  summary Fission Yeast Phenotype Ontology

`* project page - `[`https://sourceforge.net/apps/trac/pombase/wiki/FissionYeastPhenotypeOntology`](https://sourceforge.net/apps/trac/pombase/wiki/FissionYeastPhenotypeOntology)\
`* `<a href="http://bioinformatics.oxfordjournals.org/content/early/2013/06/03/bioinformatics.btt266.full">`FYPO: the fission yeast phenotype ontology `</a>`Harris et al, Bioinformatics`

Note that the OWL axioms for FYPO are managed directly in the FYPO
project repo, we do not duplicate them here


text:
1.  summary Drosophila Phenotype Ontology

`* `[`The` `Drosophila` `phenotype`
`ontology`](http://www.jbiomedsem.com/content/4/1/30/abstract)` Osumi-Sutherland et al, J Biomed Sem.`

The DPO is formally a subset of FBcv, made available from
<http://purl.obolibrary.org/obo/fbcv/dpo.owl>

Phenotypes in FlyBase may either by assigned to FBcv (dpo) classes, or
they may have a phenotype\_manifest\_in to FBbt (anatomy).

For integration we generate the following ontologies:

`* `[`http://purl.obolibrary.org/obo/upheno/imports/fbbt_phenotype.owl`](http://purl.obolibrary.org/obo/upheno/imports/fbbt_phenotype.owl)\
`* `[`http://purl.obolibrary.org/obo/upheno/imports/uberon_phenotype.owl`](http://purl.obolibrary.org/obo/upheno/imports/uberon_phenotype.owl)\
`* `[`http://purl.obolibrary.org/obo/upheno/imports/go_phenotype.owl`](http://purl.obolibrary.org/obo/upheno/imports/go_phenotype.owl)\
`* `[`http://purl.obolibrary.org/obo/upheno/imports/cl_phenotype.owl`](http://purl.obolibrary.org/obo/upheno/imports/cl_phenotype.owl)

(see Makefile)

This includes a phenotype class for every anatomy class - the IRI is
suffixed with "PHENOTYPE". Using these ontologies, Uberon and CL
phenotypes make the groupings.

We include

`* `[`http://purl.obolibrary.org/obo/upheno/dpo/dpo-importer.owl`](http://purl.obolibrary.org/obo/upheno/dpo/dpo-importer.owl)

Which imports dpo plus auto-generated fbbt phenotypes.

The dpo-importer is included in the [MetazoanImporter]

Additional Notes
----------------

We create a local copy of fbbt that has "Drosophila " prefixed to all
labels. This gives us a hierarchy:

`* eye phenotype (defined using Uberon)`\
` * compound eye phenotype  (defined using Uberon)`\
`  * drosophila eye phenotype (defined using FBbt)`

TODO
----

`* `[`http://code.google.com/p/cell-ontology/issues/detail?id=115`](http://code.google.com/p/cell-ontology/issues/detail?id=115)` ensure all CL to FBbt equiv axioms are present (we have good coverage for Uberon)`


text:
1.  summary Mouse Phenotype Ontology
2.  labels Featured

Links
=====

`* `[`The` `Mammalian` `Phenotype` `Ontology:` `enabling` `robust`
`annotation` `and` `comparative`
`analysis`](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2801442/)` Smith CL, Eppig JT`\
`* `[`MP` `browser` `at`
`MGI`](http://www.informatics.jax.org/searches/MP_form.shtml)\
`* `[`MP` `in`
`OntoBee`](http://www.ontobee.org/browser/index.php?o=MP)\
`* `[`MP` `in` `OLSVis`](http://ols.wordvis.com/q=MP:0000001)

OWL Axiomatization
==================

The OWL axioms for MP are in the
[src/ontology/mp](http://phenotype-ontologies.googlecode.com/svn/trunk/src/ontology/mp/)
directory on this site.

`* `[`http://purl.obolibrary.org/obo/mp.owl`](http://purl.obolibrary.org/obo/mp.owl)` - direct conversion of MGI-supplied obo file`\
`* `[`http://purl.obolibrary.org/obo/mp/mp-importer.owl`](http://purl.obolibrary.org/obo/mp/mp-importer.owl)` - imports additional axioms, including the following ones below:`\
`       * `[`http://purl.obolibrary.org/obo/mp.owl`](http://purl.obolibrary.org/obo/mp.owl)\
`       * `[`http://purl.obolibrary.org/obo/upheno/imports/chebi_import.owl`](http://purl.obolibrary.org/obo/upheno/imports/chebi_import.owl)\
`       * `[`http://purl.obolibrary.org/obo/upheno/imports/uberon_import.owl`](http://purl.obolibrary.org/obo/upheno/imports/uberon_import.owl)\
`       * `[`http://purl.obolibrary.org/obo/upheno/imports/pato_import.owl`](http://purl.obolibrary.org/obo/upheno/imports/pato_import.owl)\
`       * `[`http://purl.obolibrary.org/obo/upheno/imports/go_import.owl`](http://purl.obolibrary.org/obo/upheno/imports/go_import.owl)\
`       * `[`http://purl.obolibrary.org/obo/upheno/imports/mpath_import.owl`](http://purl.obolibrary.org/obo/upheno/imports/mpath_import.owl)\
`       * `[`http://purl.obolibrary.org/obo/mp/mp-equivalence-axioms-subq-ubr.owl`](http://purl.obolibrary.org/obo/mp/mp-equivalence-axioms-subq-ubr.owl)\
\

Status
======

The OWL axiomatization is updated frequently to stay in sync with
changes in the MP

Editing the axioms
==================

The edit file is currently:

`* `[`http://purl.obolibrary.org/obo/mp/mp-equivalence-axioms-edit.owl`](http://purl.obolibrary.org/obo/mp/mp-equivalence-axioms-edit.owl)

Edit this in protege.

The file mp-equivalence-axioms.obo is DEPRECATED!

TermGenie
=========

`* `[`http://mp.termgenie.org/`](http://mp.termgenie.org/)\
`* `[`http://mp.termgenie.org/TermGenieFreeForm`](http://mp.termgenie.org/TermGenieFreeForm)


text:
1.  summary Human Phenotype Ontology
2.  labels Featured

Links
=====

`* `[`http://www.human-phenotype-ontology.org/`](http://www.human-phenotype-ontology.org/)\
`* Köhler S, Doelken SC, Mungall CJ, Bauer S, Firth HV, Bailleul-Forestier I, Black GC, Brown DL, Brudno M, Campbell J, FitzPatrick DR, Eppig JT, Jackson AP, Freson K, Girdea M, Helbig I, Hurst JA, Jähn J, Jackson LG, Kelly AM, Ledbetter DH, Mansour S, Martin CL, Moss C, Mumford A, Ouwehand WH, Park SM, Riggs ER, Scott RH, Sisodiya S, Van Vooren S, Wapner RJ, Wilkie AO, Wright CF, Vulto-van Silfhout AT, de Leeuw N, de Vries BB, Washingthon NL, Smith CL, Westerfield M, Schofield P, Ruef BJ, Gkoutos GV, Haendel M, Smedley D, Lewis SE, Robinson PN. The Human Phenotype Ontology project: linking molecular biology and disease through phenotype data. `<em>`Nucleic Acids Res.`</em>`2014 Jan;`<strong>`42`</strong>`(Database issue):D966-74 [`<a href="http://www.ncbi.nlm.nih.gov/pubmed/24217912" onclick="window.open(this.href); return false;">`pubmed`</a>`]`

`* `[`HPO`
`browser`](http://www.human-phenotype-ontology.org/hpoweb/showterm?id=HP:0000118)\
`* `[`HP` `in`
`OntoBee`](http://www.ontobee.org/browser/index.php?o=HP)\
`* `[`HP` `in` `OLSVis`](http://ols.wordvis.com/q=HP:0000001)

OWL Axiomatization
==================

The OWL axioms for HP are in the
[src/ontology/hp](http://phenotype-ontologies.googlecode.com/svn/trunk/src/ontology/hp/)
directory on this site.

The structure is analagous to that of the [MP].

Status
======

The OWL axiomatization is updated frequently to stay in sync with
changes in the MP

Editing the axioms
==================

The edit file is currently:

`* `[`http://purl.obolibrary.org/obo/hp/hp-equivalence-axioms-subq-ubr.owl`](http://purl.obolibrary.org/obo/hp/hp-equivalence-axioms-subq-ubr.owl)

Edit this in protege.


text:
Introduction
============

This page describes the generation of the zebrafish phenotype ontology

Details
=======

The ZP differs considerably from [HP], [MP] and others. ZFIN do not
annotate with a pre-composed phenotype ontology - all annotations
compose phenotypes on-the-fly using a combination of PATO, ZFA, GO and
other ontologies.

We use these combinations to construct ZP on the fly, by naming each
distinct combination, assigning it an ID, and placing it in the
hierarchy.

The process is described here:

-   Sebastian Köhler, Sandra C Doelken, Barbara J Ruef, Sebastian Bauer,
    Nicole Washington, Monte Westerfield, George Gkoutos, Paul
    Schofield, Damian Smedley, Suzanna E Lewis, Peter N Robinson,
    Christopher J Mungall (2013) [Construction and accessibility of a
    cross-species phenotype ontology along with gene annotations for
    biomedical research](http://f1000research.com/articles/2-30/v1)
    F1000Research

The OWL formalism for ZFIN annotations is described here:

-   [<https://docs.google.com/document/d/1Vbokc9aFHR4awNE6DrrLtgpE6axeTS4VEfxqDHsWyPQ/edit>\#
    Mapping ZFIN phenotypes to OWL]

The java implementation is here:

-   https://github.com/sba1/bio-ontology-zp

OWL Axiomatization
==================

The OWL axioms for ZP are in
[zp.owl](https://compbio.charite.de/hudson/job/zp-owl/lastSuccessfulBuild/artifact/)
that is build on our hudson server.


text:
# The Unified Phenotype Ontology (uPheno) meeting series

The uPheno editors call is held every second Thursday (bi-weekly) on Zoom, provided by members of the Monarch Initiative and co-organised by members of the Alliance and Genome Resources. If you wish to join the meeting, you can open an issue on https://github.com/obophenotype/upheno/issues with the request to be added, or send an email to phenotype-ontologies-editors@googlegroups.com.

The meeting coordinator (MC) is the person charged with organising the meeting. The current MC is Ray, @rays22.

## Meeting preparation

- The MC prepares the agenda in advance: everyone on the call is very busy and our time is precious.
- Every agenda item has an associated ticket on GitHub, and a clear set of action items should be added in [GitHub Tasklist syntax](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists) to the _first comment_ on the issue.
   - If there are issues for any subtasks (e.g. PATO or Uberon edits), the list should be edited to link these.
   - Any items that do not have a subissue but do involve changes to patterns) should be edited to link to implementing PR.
   - It does not matter who wrote the first issue comment, the uPheno team can simply add a tasklist underneath the original comment and refine it over time.
   - Tag all issues which need discussion with "upheno call"
   - It _must_ be clear from the task list what the uPheno team should be doing during the call (discuss, decide, review). For example, one item on the task list may read: "uPheno team to decide on appropriate label for template".
   - Conversely, no issue should be added to the agenda that does not have a clear set of action items associated with it _that should be addressed during the call_. These actions may include making and documenting modelling decisions.
- Go through up to 10 issues on the [uPheno issue tracker](https://github.com/obophenotype/upheno/issues) before each meeting to determine how to progress on them, and add action items. Only if they need to be discussed, add the "upheno call" label.

## Meeting

- Every meeting should start with a quick (max 5 min, ideally 3 min) overview of all the goals and how they processed. The MC should mention all blockers and goals, even the ones we did not make any progress on, to keep the focus on the priorities:
   - uPheno releases
   - uPheno documentation
   - Pattern creation
   - Patternisation: The process of ensuring that phenotype ontologies are using uPheno conformant templates to define their phenotypes.
   - Harmonisation: The process of ensuring that phenotype patterns are applied consistently across ontologies.
- For new pattern discussions:
   - Every new pattern proposal should come with a new GitHub issue, appropriately tagged.
   - The issue text should detail the use cases for the pattern well, and these use cases should also be documented in the "description" part of the DOSDP YAML file. Uses cases should include expected classifications and why we want them (and potentially classifications to avoid).  e.g. axis-specific dimension traits should classify under more abstractly defined dimension traits which in term should classify under Morphology. Add some examples of contexts where grouping along these classifications is useful.
- Agenda items may include discussion and decisions about more general modelling issues that affect more than one pattern, but these should also be documented as tickets as described above.

## After the meeting

- After every meeting, update all issues discussed on GitHub and, in particular, clarify the remaining action items.
- Ensure that the highest priority issues are discussed first.