Skip to content

Latest commit

 

History

History
83 lines (54 loc) · 7.67 KB

CONTRIBUTING.md

File metadata and controls

83 lines (54 loc) · 7.67 KB
Raw

Human Disease Ontology Contributor Guidelines

We value every ✨contribution✨.    Thank you! 👏

Table of Contents

  1. Introduction
  2. Contributing Guidelines
    2.1. Issues Preferred
    2.2. Issue Templates
  3. What to Expect from Us
  4. Contact Information
  5. Additional Information

1. Introduction

This document describes how to make contributions and requests related to data in the Human Disease Ontology (DO). We want it to be easy 💪, for both beginners and experts. All suggestions for improvement and requests for new data are welcome. The inclusion of supporting documentation and author ORCiD IDs for attribution, are also highly appreciated 🙏.

If you have a request or suggestion regarding the display or functionality of disease-ontology.org, please contact us directly.

When contributing, please adhere to our Code of Conduct.

2. Contributing Guidelines

2.1. Issues Preferred

We strongly encourage contributors to use GitHub issues instead of pull requests to propose and discuss changes. Using issues allows for collaborative discussion, consensus building, and thorough review before they are implemented.

Pull requests (PRs) are generally harder to create and harder to review with current ontology editing tools, requiring more effort on your part and ours.

2.2. Issue Templates

A number of issue templates have been created to streamline the contribution process. Each type identifies requested information to enable our team to address the issue, along with additional information that would be helpful to include. We request that users utilize the issue templates.

🕙 Your time is valuable, we won't judge the format of your contributions. ☝️ Remember, something is always better than nothing. Please include your ORCiD ID with your request, so that we can recognize your contribution on our contributors page.

If you have suggestions for new or existing templates, or an issue that is not covered by a template, please use a blank issue or contact us directly.

3. What to Expect from Us

Always expect a cordial and timely response. When requests are straightforward and accepted, expect the issue to be implemented and closed with little, if any, additional back and forth comments. When issues are complex or expanded upon, we may provide or request further information on the issue to support or outline decision-making. Discussions are always welcome, it aids curation and decision-making, but don't feel obligated to reply. If for some reason changes suggested or requested will not be implemented, we will explain why in a comment posted to the issue. If you disagree or just feel a desire to comment further, please do!

4. Contact Information

If you have questions or need further assistance, please feel free to reach out to us:

Thank you for your interest in contributing to the Human Disease Ontology. Your contributions play a vital role in maintaining this valuable resource for the scientific and medical community.

5. Additional Information

For those new to the Human Disease Ontology, or just wishing to better understand how it's organized or what's in it 😉.

Curation

Curation of the ontology follows established procedures and patterns that are outlined on the disease-ontology.org Curation page. However, diseases are not static entities! Continuous updates and revisions are required to incorporate new knowledge. To suggest changes to design patterns or procedures governing data in the Human Disease Ontology, please open a blank issue or contact us directly.

Data in the Ontology

  • Diseases are organized hierarchically based on their etiology (or cause, one of many possible classifications), in a directed acyclic graph (DAG) providing a conceptual representation of the relatedness of human diseases.

  • In the Human Disease Ontology, each disease record includes:

    • Uniform Resource Identifier (URI): A persistent, web-accessible URL and ID (example: http://purl.obolibrary.org/obo/DOID_4).
    • label: The current, active disease name (example: 'syndrome').
    • ID: A short version of the URI using the approved, OBO Foundry prefix 'DOID' (example: DOID:4).
    • OBO namespace: The namespace assigned to the DO by the OBO Foundry ('disease_ontology').
    • parent/superclass: One or more curator-asserted, direct disease-to-disease relationship(s) using rdfs:subClassOf in OWL or is_a in OBO files (example: the parent of syndrome is disease).

  • Additional data which may be available for a disease, includes:

    • definition: A human-readable text definition, written by a DO curator. Most DO diseases have textual definitions. All definitions have supporting sources (specified as xrefs).
    • synonym(s): Alternate names for a disease. These include historical and alternate names or acronyms, and may be exact, narrow, broad, or related in nature, denoted by oboInOwl annotations.
    • xref(s): Cross-references to other clinical vocabularies (e.g. NCI Thesaurus, OMIM, Orphanet, GARD, UMLS, SNOMED CT, ICD).
    • skos mapping(s): Denoting the level of similarity between the DO term and the cross-reference ID, organized by the nature of the mapping using the Simple Knowledge Organization System (SKOS) (e.g., exact, close, narrow, broad, or related).
    • logical statements: Curator-asserted disease-to-feature relationships using terms from ontologies imports (phenotype, cell type, age of onset, anatomy, taxonomy, cell, symptom, transmission method, sequence variant type).
    • deprecated: A boolean utilized to indicate whether a disease has been deprecated, or no longer active. Only present on obsoleted or merged disease terms. These terms are included in the DO ontology files, but are not shown on the DO website.
    • alternate ID(s): Alternate IDs for diseases that have been merged into another DOID. DOIDs for merged or obsoleted terms pre-dating the use of OWL (<2015) may not be present in current ontology files, but can be found in the DO's Sourceforge repository.
    • term_replaced_by: An annotation that is utilized to denote the term an obsoleted term was merged into, where applicable.