Perturbing Pathway Models

Below are "design theories" on the best ways to change one well-formed pathway model into another one adjusted for an abnormal context - one influenced by some disease, drug, etc.  This should generally be doable at maximum ease, power and elegance, but WITHOUT forcing related changes to any constraints in the BioPAX Ontology.

One cannot modify a BioPAX pathway model by adding RDF/OWL statements to it.  If you could, the original model would involve a form of logic that was non-monotonic.  When Deb McGuinness et al designed OWL-DL, they felt that was too complex, and barred it.

So by design, OWL itself blocks any use case for RDF/OWL-DL which involves changing the facts within a BioPAX pathway model by adding new ones.  All one can do is extend the facts some reasoner uses, while leaving in place all the others.

Sadly, this limit also applies whenever complex models are merged, as from the viewpoint of each one, all the others will be merely additions. So if you think a pathway model can be customized to its biological context by just merging files, please think again.   At best, this will only work in special cases (but skip ahead to Theory 4. before going further)..

THEORY 1 - WHAT MIGHT WORK (SOMEDAY)

Using only additions makes it relatively hard to perturb a pathway model as generally desired. Any straightforward approach would just cause parts of its model to be selectively ripped out and replaced, to account for effects of disease, drugs, genomic mutations, etc. That "ripping out" is the specific piece logically banned within OWL-DL.

It seems possible to emulate this inside the OWL-DL model by making all pathway models extremely modular, so that they can be assembled in any form needed, not mutated . This seems complex to arrange in the general case

Moving outside the OWL-DL processing model could become even more complex, as this would violate basic usage premises that all BioPAX models are now being built to meet.  Using more advanced forms of logic may require new research in logic programming.

Both approaches above have R&D and usage costs that seem high compared to their short-term benefits, especially if the next simpler alternative is adequate.

THEORY 2 - WHAT COULD WORK MUCH SOONER (SORT OF)

Absent validation hazards, manual edits of RDF/OWL-DL files under a Copy-and-Modify pattern can handle the basic task of perturbing just fine. Model usage premises survive, and if pathway source files are kept reasonably modular and annotated, changing any model should be straightforward.

Conceptually, with only minutes of keyboarding, you can perturb each model in any way you want, under any merged or imagined context model you wish to test.  This strategy is less sexy than non-monotonic logic, but it does the job and terminates in predictable time. If early results get published, a whole community can learn from them, reuse techniques, and possibly even reuse most data models.

Of course, to repeat such edits in a few (hundred) variations, or deal with large files might take many tedious hours at your PC. Plus more to name and archive all the perturbed result files, then test each one against some query or inferencing process.   But with modest diligence, in theory, all of this is doable.

Errors would be problems, as editors are only human, and so are those who want to review tests and results. They might dislike checking RDF files to learn how models were perturbed. So even though this strategy works in theory, some kind of framework seems needed to make the tactics more automated, disciplined, elegant, user-friendly, repeatable, and accurate.

THEORY 3 - CHARTS HELP CONTEXT MODELS EVOLVE

This charting web app is designed to be a flexible open toolkit for assembling and mutating metadata models by using flexible formal graph paradigms, an open base of scripted edit commands, and the combined insights of any interested group of scientists .

Each copy should run fine on a public web server, on your work group's intranet, and/or on the PCs and laptops of research staff. Each copy acts as a small warehouse for pathway and context models, plus related scripts, all of which can be easily web-shared.

As a suite for reviewing annotated BioPAX pathways, this web app would help any group collaborate about the models it needs, or edit them with change management support.  But it would not try to reason deeply about any pathway model until its file-export time, when an RDF/OWL file for the whole context would be formally built and validated.

Until then, the web app can load and help edit models using an intermediate language of abstract graphs.  With TMAPI "triple" storage and XHTML charts, a web user can visualize, author, and search these graphs easily. They can also call and/or create scripts to help - using JSPs, Java classes, or a built-in WORDS command language, any of which can be driven by web forms and/or files of interpreted Scheme, Python, VB.Net, etc.

THEORY 4 - PERMIT ANY WELL-FORMED PATHWAY PARTS

A "special case" of Theories 0-1 seems to exist in all early releases of BioPAX - they are  are 100% open with respect to parts of pathways.  This freedom essentially removes all formal OWL barriers to "perturbing" them manually or with scripts.

Restrictions to pathway parts in later ontology releases should thus be added with care, as beyond the limits they establish, perturbations of a pathway will be inhibited