DOCSEARCHbyAlgolia
Submit Docs

Pronto: Python frontend to ontologies

repository·master·Indexed 42 days ago

https://github.com/althonos/pronto

A Python library for parsing, browsing, creating, and exporting ontologies. It provides a high-level interface for working with Open Biomedical Ontologies (OBO) 1.4, OBO Graphs (JSON), and OWL2 (RDF/XML). The library features an Ontology class for managing terms and a layered architecture (Ontology, View, Model, and Data layers) to separate high-level abstractions from raw data.

Tokens
11.4K
Snippets
44
Records
53
Agent score
53%

What's inside Pronto

  1. How to interact with the View Layer

    master

    The View Layer provides the primary interface for working with ontology entities. Classes in this layer, such as Term, Entity, Relationship, Synonym, and TermSet, are designed to ensure data integrity by tracking the ontology context in which they were declared.

    Constraint: To ensure proper verification (e.g., checking that a Synonym type is valid for a specific ontology), never create View Layer objects manually. Always use the factory methods provided by an Ontology or Entity instance.

    Example Pattern: To get a new term, use Ontology.get_term() rather than attempting to instantiate pronto.Term directly.

  2. Understand the Pronto architecture layers

    master

    Pronto is organized into several layers that separate the high-level ontology abstraction from the underlying raw data. Understanding these layers is crucial for knowing how to interact with the library:

    1. Ontology Layer: The primary abstraction representing a $\mathcal{SHOIN}^{(D)}$ ontology.
    2. View Layer: Contains classes like Term, Entity, Relationship, Synonym, and TermSet. These classes maintain references to the ontology they belong to for verification. Important: Do not instantiate View Layer classes manually. Instead, obtain them through methods on existing Ontology or Entity instances (e.g., using Ontology.get_term() to retrieve a Term).
    3. View Collections: Specialized collections (like Relationships) that provide a view of specific entity fields. These are accessed via properties on Entity instances and cannot be instantiated directly.
    4. Model Layer: Lightweight classes (e.g., Metadata, Definition, Xref, SynonymType) that represent specific data attributes. Unlike the View Layer, these can be instantiated directly and passed to View Layer functions or properties.
    5. Data Layer: Classes that store raw data extracted from ontology files (e.g., TermData, RelationshipData). These are primarily intended for use when implementing custom parsers.

  3. How the Ontology class works

    master

    The Ontology class is the main entry point for the library. It allows you to parse, browse, create, and export ontologies. You can instantiate it using a local file path (including compressed files like .gz), a persistent URL, or via the from_obo_library method for OWL files.

    Ontology objects act as mappings, allowing you to access Term objects directly using their accession/identifier (e.g., ontology['ID']).

    from pronto import Ontology

# Load from a local compressed file
go = Ontology("tests/data/go.obo.gz")

# Load from a URL
cl = Ontology("http://purl.obolibrary.org/obo/cl.obo")

# Load an OWL ontology
stato = Ontology.from_obo_library("stato.owl")

# Access a term by accession
term = cl['CL:0002116']

  4. Migrate ontology exporting from v0.* to v2.*

    master

    In v2.*, exporting an ontology to OBO or other supported formats is performed using the Ontology.dump (for file objects) and Ontology.dumps (for strings) methods. The previous property-based access (e.g., ontology.obo) is no longer supported.

    # before
print(ontology.obo)
open("out.obo", "w").write(ontology.obo)

# after
print(ontology.dumps(format="obo"))
ontoloy.dump(open("out.obo", "w"), format="obo")

  5. Install pronto via pip or conda

    master

    You can install pronto using pip or conda.

    For pip, use the --user flag if you do not have administrative rights to install to the system directory.

    For conda, use the bioconda channel.

    # Using pip
$ pip install pronto --user

# Using conda
$ conda install -c bioconda pronto

  11. Migrate subclass and superclass access from v0.* to v2.*

    master

    Pronto now follows RDF semantics for subclassing relationships. The methods rchildren() and rparents() have been replaced by subclasses() and superclasses().

    Key changes to note:

    • Return Type: These methods now return an iterator instead of a TermList.
    • Self-inclusion: By default, any class is considered its own subclass and superclass. The iterator will yield the term itself as the first member.
    • Filtering: Use with_self=False to exclude the term itself from the results.
    • Depth Control: Use distance=1 to retrieve only direct subclasses or superclasses (replicating the old rchildren/rparents behavior).
    • Converting to TermSet: If your existing code requires a TermSet instead of an iterator, use the .to_set() method on the resulting iterator.
    # before
children: pronto.TermList = term.rchildren()
parents: pronto.TermList = term.rparents()

# after
# Basic usage (includes self)
children_iter: Iterable[Term] = term.subclasses()
parents_iter: Iterable[Term] = term.superclasses()

# To get only true subclasses/superclasses (excluding self)
children_iter: Iterable[Term] = term.subclasses(with_self=False)
parents_iter: Iterable[Term] = term.superclasses(with_self=False)

# To get only direct subclasses/superclasses (equivalent to old behavior)
children: Iterable[Term] = term.subclasses(with_self=False, distance=1)
parents: Iterable[Term] = term.superclasses(with_self=False, distance=1)

# To convert the iterator back to a TermSet for compatibility
children: pronto.TermSet = term.subclasses().to_set()
parents: pronto.TermSet = term.superclasses().to_set()