Interface: ScenarioRuleTerm
@kortexya/reasoninglayer / ScenarioRuleTerm
Interface: ScenarioRuleTerm
Section titled “Interface: ScenarioRuleTerm”Defined in: src/types/scenarios.ts:240
One term of a ScenarioRule: its conclusion or one of its conditions.
Remarks
Section titled “Remarks”In GeneratedScenario.rules the term goes out as written. In
UpdateScenarioRequest.addRules it is mapped field by field, so a key
outside sort, features, negated and binding does not go out.
features is user data and goes out as written, in the REST rule encoding:
"?X", {"name":"?X"} and {"_var":"?X"} are variables shared across the
rule, and a literal string that starts with ? is written as the typed
envelope {"type":"String","value":"?x"}.
Example
Section titled “Example”const topping: ScenarioRuleTerm = { sort: 'topping', binding: '?T' };const vegetarian: ScenarioRuleTerm = { sort: 'meat_topping', negated: true, binding: '?T' };Properties
Section titled “Properties”binding?
Section titled “binding?”
optionalbinding?:string
Defined in: src/types/scenarios.ts:257
The antecedent’s own identity, named ("?P", with or without the ?) —
OSFQL’s ?P: pizza(...). On a positive antecedent every "?P" elsewhere
in the rule references the term it matches; on a negated one it names the
term the negation is about, which a positive antecedent must bind.
Meaningless on a head.
features?
Section titled “features?”
optionalfeatures?:Record<string,unknown>
Defined in: src/types/scenarios.ts:244
Feature constraints, in the REST rule encoding. Defaults to {}.
negated?
Section titled “negated?”
optionalnegated?:boolean
Defined in: src/types/scenarios.ts:249
On an antecedent: negation as failure — it holds when the pattern is NOT
provable. Defaults to false.
sort:
string
Defined in: src/types/scenarios.ts:242
Sort name.