Rules
pd2af.asp.rules
ASP rule composition for the pd2af transformation modes.
Which groups a mode is made of is declared by the mode itself
(:mod:pd2af.modes); this module owns the groups and composes the program
text for a named mode. The rules are organised in layers:
- topology:core (shared) — structural helpers:
isSubunit,hasActiveDescendantSubunit. - topology:top_level (the complex-keeping modes
normalandkeep-reactions) —resolvesToTopLevel(SPECIES, TOPLEVEL)resolves every species to its outermost top-level entity, so a subunit is keyed by (and its influences routed to) its top-level complex rather than itself. - preparation (a
slot: exactly one filler group per mode, and every consumer of the activity-key predicates depends on the slot rather than on a particular filler) — emitshasActivityCarrier(RAW_SPECIES, ACTIVITY_BEARER)andhasActivityKey(ACTIVITY_BEARER, KEY)whereKEYis one of two per-species wrappers:keptSpeciesKey/1(top-level species, and the top-level complex a subunit resolves to) orpromotedSubunitKey/1(a subunit promoted to top level when its complex is dissolved in theno-complexmode). PTM stripping, which merges the forms of the same base entity unlesskeep_speciesis set, happens at the build stage, not in the key. - influences:core (shared) — emits
new(activity(KEY))andnew(positivelyInfluences(...))/new(negativelyInfluences(...))fromhasActivityCarrier/hasActivityKey. The inference layers on top of it — multi-hoppaths:chaining,influences:consumptionandinfluences:binding_activation— are carried by the two path-inference modes only.
The keep-reactions mode reuses that whole scaffolding and swaps
discovery and inference for two rules: every species is an activity
(keep_reactions:activity) and every (reactant, product) pair of a reaction
is a positive influence (keep_reactions:influences). It keeps the single-hop
modulation influences of paths:core and drops the inference layers.
Functions:
| Name | Description |
|---|---|
build_program |
Return the composed ASP program text for a mode and an input language. |
build_registry |
Register the built-in rule groups plus every group the modes define. |
get_excludable_groups |
Return |
build_program
build_program(mode: TransformationMode, language: Language = CELLDESIGNER, exclude_groups: tuple[str, ...] = (), exclude_rules: tuple[str, ...] = ()) -> str
Return the composed ASP program text for a mode and an input language.
The mode names the groups its program is made of; the input language is an
aspcompose variant. Language-agnostic rules live in each group's
rules and are emitted for every language; language-specific rules live
in variants={Language.CELLDESIGNER: ..., Language.SBGN_PD: ...} and are selected here
by resolve(variant=language).
exclude_groups drops whole rule groups (the primary toggle: each
excludable group is a coherent functional unit); excluding a group that
another included group depends on raises ValueError with a friendly
message. exclude_rules is a finer scalpel that drops individual rules
by identifier (used for the whole-with-scalpel table groups); an id that
does not name a resolved rule raises ValueError.
Source code in src/pd2af/asp/rules.py
build_registry
build_registry(modes: Iterable[TransformationMode] | None = None) -> RuleRegistry
Register the built-in rule groups plus every group the modes define.
modes is an iterable of :class:pd2af.modes.TransformationMode,
defaulting to every known mode. Passing a narrower set — the built-in modes
alone, say — yields a registry that ignores contributed groups.
Two modes may not define the same group id, and every group a mode references must be registered; either raises naming the mode.
Source code in src/pd2af/asp/rules.py
get_excludable_groups
Return (excludable, mandatory) group ids for a transformation mode.
A group is mandatory when another included group depends on it (the
dependency graph forbids excluding it — resolve would raise
excluded_dependency); every other included group is an excludable
leaf that --exclude-group can drop cleanly. A dependency on a slot
resolves to the included group filling it, so a filler is mandatory
exactly like a directly named dependency.