Home >> All >> com >> hp >> hpl >> jena >> reasoner >> rulesys >> [ impl Javadoc ]

•	com.hp.hpl.jena.reasoner.rulesys.impl.oldCode.* (18)

• com.hp.hpl.jena.reasoner.rulesys.impl: Javadoc index of package com.hp.hpl.jena.reasoner.rulesys.impl.


Package Samples:

• com.hp.hpl.jena.reasoner.rulesys.impl.oldCode: Internal implementation objects used by the rule system interpreters and compilers.  

Classes:

• OWLRuleReasonerFactory: Obsoleted post jena2.0, replaced by com.hp.hpl.jena.reasoner.rulesys.OWLFBRuleReasonerFactory . Factory class for creating blank instances of the OWL Reasoner. The reasoner can be configured using three properties (set as properties of the base reasonder URI in a configuration model). These are: derivationLogging - if set to true this causes all derivations to be recorded in an internal data structure for replay through the getDerivation 55 method. traceOn - if set to true this causes all rule firings and deduced triples to be written out to the Log at INFO level. ruleThreshold - which limits the ...
• OWLExptRuleReasonerFactory: Experimental change to the OWL hybrid rule reasoner. Factory class for creating blank instances of the OWL Reasoner. The reasoner can be configured using three properties (set as properties of the base reasonder URI in a configuration model). These are: derivationLogging - if set to true this causes all derivations to be recorded in an internal data structure for replay through the getDerivation 55 method. traceOn - if set to true this causes all rule firings and deduced triples to be written out to the Log at INFO level. ruleThreshold - which limits the number of rules that can be fired on a single ...
• GoalResults: Part of the backward chaining rule interpreter. The goal table is a table of partially evaluated goals. Each entry is an instance of GoalResults which contains the goal (a generalized triple pattern which supports structured literals), a set of triple values, a completion flag and a generator (which represents a continuation point for finding further goal values). This is essentially an encapsulation of the OR graph of the evaluation trace. This implementation is not very space efficient. Once a GoalResult is complete we could flush all the results out to a single shared deductions graph in the ...
• RuleState: Part of the backward chaining rule interpreter. A RuleState represents the state of a partially expanded search tree for a single Rule. The RuleStates are linked back in an OR tree to a root goal which is being satisfied. Each RuleState shares a pointer to a RuleInstance which holds references for the rule being processed and the goal which the rule is satisfying. Encapuslation warning: this object is used in the tight inner loop of the engine so we access its field pointers directly rather than through accessor methods.
• OWLRuleReasoner: Obsoleted post jena2.0, replaced by com.hp.hpl.jena.reasoner.rulesys.OWLFBRuleReasoner . An pure forward chaining implementation of the experimental OWL closure rules based upon the basic forward rule interpreter. This is not a serious or usable OWL implementation, it is a tool for developing the rules. TODO: Replace intersection-translation step by rule based alternative (or failing that figure out what should be done at the bindSchema stage).
• Generator: A generator represents a set of memoized results for a single tabled subgoal. The generator may be complete (in which case it just contains the complete cached set of results for a goal), ready (not complete but likely to product more results if called) or blocked (not complete and awaiting results from a dependent generator). Each generator may have multiple associated consumer choice points representing different choices in satisfying the generator's goal.
• RuleInstance: Part of the backward chaining rule interpreter. A RuleInstance links an instance of a rule to the GoalResults object for which it is generating results. It is a simple data structure which is shared amongst a set of RuleSets to reduce the store turn over needed for RuleState creation. Encapuslation warning: this object is used in the tight inner loop of the engine so we access its field pointers directly rather than through accessor methods.
• ConsumerChoicePointFrame: Frame in the LPInterpreter's control stack used to represent matching to the results of a tabled predicate. Conventionally the system state which finds and tables the goal results is called the generator and states which require those results are called consumers. This is used in the inner loop of the interpreter and so is a pure data structure not an abstract data type and assumes privileged access to the interpreter state.
• BRuleEngine: Part of the backward chaining rule interpreter. Maintains an agenda containing an ordered list of RuleStates awaiting processing (each RuleState represents the tip of a partially expanded search tree). This object does the top level scheduling of rule processing. By default it batches up several results from the top rule in the agenda before switching to expand other trees. The size of this batch is adjustable.
• OrigFBRuleInfGraph: An inference graph that uses a mixture of forward and backward chaining rules. The forward rules can create direct deductions from the source data and schema and can also create backward rules. A query is answered by consulting the union of the raw data, the forward derived results and any relevant backward rules (whose answers are tabled for future reference).
• FBLPRuleReasoner: Rule-based reasoner interface. This is the default rule reasoner to use. It supports both forward reasoning and backward reasoning, including use of forward rules to generate and instantiate backward rules. This version is purely temporary during development of the LP engine and will get replaced by the upgraded FBRuleReasoner when the LP section is released.
• EnvironmentFrame: Represents a single frame in the LP interpreter's environment stack. The environment stack represents the AND part of the search tree - it is a sequence of nested predicate calls. This is used in the inner loop of the interpreter and so is a pure data structure not an abstract data type and assumes privileged access to the interpreter state.
• GoalState: Represents the state in a traversal of all the solutions of a given goal. This will traverse, in turn, all the matches in the underlying triple stores, all the memoized results currently in the GoalTable and then all the additional results which can be found by turns of the goal Generator crank, until the goal (or the whole derivation) is complete.
• TempNodeCache: In some rules we need to be able to create temporary property values which are inferred from ontology constraints but not present in the ground data. This structure is used to manage a pool of such temporary nodes. It is only needed in situations where the data can not be added directly to a deductions graph due to the risk of concurrent access.
• GenericTripleMatchFrame: Frame on the choice point stack used to represent the state of some form of triple match - this is either a direct graph query or a query to a cached set of results. This is used in the inner loop of the interpreter and so is a pure data structure not an abstract data type and assumes privileged access to the interpreter state.
• GenericChoiceFrame: Core properties of choice frames used use to represent the OR state of the backtracking search. Specific variants of this need to preserve additional choice state. This is used in the inner loop of the interpreter and so is a pure data structure not an abstract data type and assumes privileged access to the interpreter state.
• LPBRuleEngine: LP version of the core backward chaining engine. For each parent inference graph (whether pure backward or hybrid) there should be one LPBRuleEngine instance. The shared instance holds any common result caching, rule store and global state data. However, all the processing is done by instances of the LPInterpreter - one per query.
• ChoicePointFrame: Represents a single frame in the LP interpreter's choice point stack, represents the OR part of the search tree. This is used in the inner loop of the interpreter and so is a pure data structure not an abstract data type and assumes privileged access to the interpreter state.
• RETEClauseFilter: Checks a triple against the grounded matches and intra-triple matches for a single rule clause. If the match passes it creates a binding environment token and passes it on the the RETE network itself. The checks and bindings are implemented using a simple byte-coded interpreter.
• RuleStore: Indexes a collection of rule. The currently implementation is a crude first version aimed at supporting the backchaining interpreter. It only indexes on predicate. The rules are normalized to only contain a single head element by duplicating any multi headed rules.
• RuleClauseCode: Object used to hold the compiled bytecode stream for a single rule clause. This uses a slightly WAM-like code stream but gluing of the clauses together into disjunctions is done in the interpreter loop so a complete predicate is represented as a list of RuleClauseCode objects.
• BindingVector: An implementation of a binding environment that maintains a single array of bound values for the variables in a rule. Stack management is done externally. This is intended for use in the Brule system and so also supports variable-variable bindings by use of reference chains.
• LPInterpreterState: Marker interface for classes than can be used to initialize the state of an LP interpreter - either an initial context (which in turn is either a top level iterator or an generator being run for the first time), or a previaous saved context (i.e. a ConsumerChoicePointFrame).
• GoalTable: Part of the backwared chaining rule interpreter. The goal table is a table of partially evaluated goals. This could be done by variant-based or sumsumption-based tabling. We currently use variant-based. TODO Investigate performance impact of switching to subsumption-based.
• TripleMatchFrame: Frame on the choice point stack used to represent the state of a direct graph triple match. This is used in the inner loop of the interpreter and so is a pure data structure not an abstract data type and assumes privileged access to the interpreter state.

Home | Contact Us | Privacy Policy | Terms of Service