Metadata-Version: 2.1
Name: camelot-frs
Version: 0.0.2
Summary: A frame representation system in Python.
Home-page: https://bitbucket.org/tomeraltman/camelot-frs/
Author: Tomer Altman
Author-email: camelot@me.tomeraltman.net
License: UNKNOWN
Description: # Camelot: A Pythonic Frame Representation System
        
        Camelot is a Frame Representation System (FRS) for Python. It is
        inspired by the Ocelot FRS which powers the Pathway Tools software
        from SRI International's Bioinformatcs Research Group. Thus, it is
        called 'Camelot' as a Pythonic Ocelot.
        
        ## Current Capabilities
        
        * Slot annotations
        
        * Transitive Closure for is-a (i.e., subsumption) and part-of relationships
        
        * Supports the import of KBs in the attribute-value format of
          Pathway/Genome Databases as generated by Pathway Tools
          
        * Implementation of select functions from the Pathway Tools API
        
        * Enrichment Analysis
        
        
        ## Planned Capabilities
        
        * Visualization of Ontology structure using GraphViz
        
        * Ties to BioPython for handling sequence data
        
        * Support data loaders for GO, ENZYME, NCBI Taxonomy DB, and UniProt
        
        ## How to Build
        
        Run the following at the top of the package repository:
        
        ```
        make clean-package
        make create-package
        ```
        
        ## How to Install
        
        
        Camelot FRS is released as a Python package. It can easily be
        installed using FIXME.
        
        To manually install the package from the Git repository, do the
        following at the top-level of the repository:
        
        ```
        make install-package
        ```
        
        For development purposes, the following will install an 'editable'
        version of the package:
        
        ```
        make install-dev-package
        ```
        
        ## A Simple Tutorial
        
        
        ```
        ## Import Camelot functions for working with ontology:
        from camelot_frs.pgdb_loader import load_pgdb
        from camelot_frs.pgdb_api    import reactions_of_compound
        from camelot_frs.camelot_frs import get_kb, get_frame, get_frames, get_frame_all_parents, get_frame_all_children
        
        ## Load MetaCyc:
        load_pgdb("/home/ubuntu/data/metacyc/23.1/data")
        
        ## Assign the MetaCyc Knowledge Base (KB) to a variable:
        metaKB = get_kb('META')
        
        ### Find all reactions of 'ACET':
        
        ## Get the frame for acetic acid:
        acet = get_frame(metaKB, 'ACET')
        
        ## Get all reactions that directly 
        
        ## Get all reactions that indirectly consume acetic acid:
        ## (Either an instance or sub-class or a super-class of acetic acid is consumed in the reaction)
        indirect_rxns = reactions_of_compound(acet, generic_rxns_p=True, consumed_p=True)
        ```
        
        ## A Tutorial using MetaCyc
        
        
        ## Design Decisions
        
        From my years of experience working with the Ocelot DB, I had some
        definite opinions about how to design the user experience with Camelot. The
        following is a summary of some of these decisions:
        
        * All KBs and frames are objects
        * There are no symbol-equivalent representations of KBs or frames
        * Since a user has to deal with objects directly, objects have a
          rational and human-readable display form, such as 'frame:proton' for
          a proton object, rather than '(Python object 0x399823498)'
        * Since all frames are represented as objects, each object points
          specifically to the KB that it comes from (and every KB has a link
          to the frames it contains). Only frame look-up functions require the
          KB as a co-argument. This greatly simplifies the code.
        * KB-agnostic code is kept strictly separate from KB-specific code
          (e.g., the PGDB Loader)
        * Core algorithms for processing ontology datastructures are separated
          out from the 'business logic' 
        * Instead of having separate functions for dealing with classes versus
          instances, functions are written to be as generic as possible, and
          named arguments are optional for specifying between them (e.g.,
          `get_frame_all_children` can specify optionally to return only
          classes, only instances, or both, which is the default)
        * All slots are lists, even if they usually only have a single value
        * Accessing a non-existent slot throws an error. Schema violations
          should cause code to fail and fail early
        
Platform: UNKNOWN
Classifier: Programming Language :: Python :: 3
Classifier: License :: OSI Approved :: Mozilla Public License 2.0 (MPL 2.0)
Classifier: Operating System :: OS Independent
Requires-Python: >=3.6
Description-Content-Type: text/markdown
