Goals, CSF, Requirements
Formal semantics
• Where rules are interchanged between different
tools and across language boundaries,
assumptions about the meaning of the rules can
be dangerous and difficult. A formal semantics
framework will reduce the potential for error in
the exchange of rules in such and may other
situations.
• Clear and precise semantics
• Phase 1
Multiple semantics
• RIF should be able to cover rule languages with
different styles of semantics, e.g.
– Operational and declarative
– Stable and well-founded and…
– Fixed-point and…
• RIF should be able to cover rule languages with
different intended semantics for the rules
• Phase 1 (understand extensibility)
Markup of semantics
• A 'no surprises' rule interchange is only possible if the
original semantics of the rule sets to be interchanged is
specified. Thus, a means is needed for specifying which
formal semantics the rule set to be interchanged has.
• RIF has a means specifying the intended semantics of
the interchanged the rule set
• The intended semantics of the rule set in a RIF
document should be characterised syntactically
• RIF should have a standard way to specify the intended
semantics (or semantics style) of the rule set in a RIF
document
• Phase 1
Meta language features
• RIF should support meta language
features such as priorities and preferences
– Priorities and preferences are semantic
annotations => go under previous req
– Discriminator => goes into rifraf
• meta rules for meta reasoning
– Language feature
– Goes into RIFRAF
• Phase 2
Meta data
• RIF should support meta data
– E.g. author, rule name
• Phase 1
• The RIF should support first order deductive rules
– RIF Core must support deduction rules
– RIF Core must cover pure Prolog (dropped)
– Extended RIF must cover FOL
• The RIF should support normative rules
– Standard RIF must support normative rules
• RIF should cover deduction rules
• RIF should cover three different classes of rule
languages, specifically: deductive (LP and FOL styles),
normative, reactive
• Phase 1 : deduction rules (with clarification, action paula)
• Goes into rifraf
• The RIF should support Prolog-like rulesets. See
Standard RIF should be Prolog-like but not Prolog-
compatible.
– dropped
• The RIF should cover production rules and ECA. This
includes all the major classes of production rule-like
systems such as RETE-based systems and Event
Condition Action rule-based systems. See Extended RIF
must support production rules.and Standard RIF must
support reactive rules
– Phase 2
– RIFRAF
Combined rulesets
• The RIF should support rule sets that are combinations
of different kinds of rules (i.e., a mixture of deductive,
normative, ECA rules and so on.) This may affect the
semantic integrity of the ruleset language: restricting the
kinds of semantics that can be ascribed to such
combined ruleset.
• The RIF should cover rule languages where rule sets
can be combinations of different kinds of rules (i.e., a
mixture of deductive, normative, ECA rules and so on.)
• Phase 2
• RIFRAF
Combined rulesets
• The RIF should support rule sets where
rules are composed of features from
multiple rule languages
• removed
• a condition in a RIF rule may be a SPARQL
query
• A RIF rule should be able to call out an external
query
• (The condition language fragment of) RIF should
include an extensible mechanism by which rules
can consult external "blackbox" information
sources or query processors.
• Phase 2 but may end up with it in P1
• RIF should support uncertain and
probabilistic information
• Needs further discussion in phase 2
Support typed languages
• RIF should be designed in such a way that
it permits the incorporation of type
system(s)
• RIF should cover typed languages
• RIF should cover rule languages where
variables are typed
• Phase 2
Support oracular models
• RIF should offer support for models that
are oracular, that is one needs to ask (a
kind of) oracle for finding what the
interpretation of RIF parts is. E.g.
procedural attachments, aggregate
functions are to be found in this category
• Further discussion
– Removed because covered by the « external
calls » requirement
Extensibility of semantics markup
• The semantics of a RIF ruleset must be
specifiable in a way that permits the
incorporation of new rule languages and
language features
• Syntactic VS semantics extensibility?
• Dropped (covered under the CSF of
extensibility)
Conformance model
• It must be clear what the conformance profile of a given
RIF ruleset is and what default processing is implied
• RIF must define expected default behaviour
• Sound reasoning with unknown dialects
– It must be possible in some practical circumstances for systems
reasoning with rulesets to soundly proceed with parts of their
work even when a ruleset contains rules which use extensions
not known to the system implementors
• RIF must specify at the appropriate level of detail the
default behaviour that is expected from a RIF compliant
application that does not have the capability to process
all or part of the rules described in a RIF document, or it
must provide a way to specify such default behaviour.
That default behaviour must be easy to implement
independently of the rule-processing capability of the
consumer application.
• Phase 1
• It should be possible to build reasoners for
intended ruleset languages without
unnecessary burden
• Replaced by RIF must be implementable...
• RIF compliance should not impose
compliance with everything in RIF
– Conformance not in the context of extensibility
– Needs to be clarified, esp. to avoid trivial
compliance
• RIF will define a compliance model that
will identify required/optional features
• Phase 1
• Reasoners for RIF should make use of
well understood implementation
techniques.
• RIF should be implementable using well
understood implementation techniques
• Phase I
• It should be possible for a RIF reasoner to
make use of standard support
technologies such as XML parsers and
other parser generators.
• RIF implementations should use standard
support technologies such as XML parsers
and other parser generators
• Phase I
• RIF implementations can be translators
from RIF to rule languages supported by
existing reasoners
• RIF should not require rule systems to be
changed, it must be implementable via
translators
• Phase 1
• Low transfer costs (real-time
requirements). Be inexpensive in
representation (cost of transfer and cost of
transformation) - RIF must be able to
accomodate real-time performance
requirements.
• Efficient implementation? Is this a CSF?
• Postponed to next WD
Support RDF
• RIF should accept RDF triples as data
– Clarification: RIF should cover the RDF data model?
• May not include b-nodes
• Binary predicates, uris,
– RIF should have a mapping from RDF
• RIF should cover RDF triples as data where compatible
with Phase I semantics
– Sandro and Gary to talk over lunch and confirm consensus to
WG
– Phase 1
• RIF shoudl cover RDF
– Phase 2
• Support RDF/XML syntax
– dropped
Support OWL
• RIF should accept OWL knowledge bases
as data (to be discussed w/ action on
JosB)
• RIF should cover OWL KBs as data where
compatible with Phase I semantics
– Chris to clarify what to do about OWL in
Phase I
• RIF should express RDF deduction rules
– RIF shoudl cover RDF deduction rules
(agreement)
– Should be a RIFRAF classification
– Phasing TBD as part of RIFRAF
• Permit SPARQL queries to be used in
rules
– Pointer to previous req.
– Covered by external call
– Phase 2, but...
Support XML
• RIF must be able to accept XML elements as
data
• The RIF core must be able to handle XML
elements defined by XML Schema as data.
– Stronger requirement: RIF « translation » of XML
Schema elements should be those elements
themselves
• RIF should permit XML information types to be
expressed using XML schema
– Not just data types, e.g. List structures are not xsd
datatypes (to be clarified – user-defined datatypes?)
• RIF will cover the set of languages
identified in RIFRAF
– We will use RIFRAF to identify classes of
languages to be covered by RIF
• Support LP semantics with negation as
failure and strong negation
– RIF should cover LP semantics with negation
as failure AND “strong negation as in DLV
and courteous”
– Strong negation is explicitly asserted
negation.
– Needs further discussion, strong relation to
RIFRAF
• Offer module construct for scoped positive
and negation as failure queries
– RIF should cover scoped queries
– RIF should cover scoped NAF queries
– Further discussion Goes into RIFRAF
• Permit restricted form of equality
– Further discussion - Put into RIFRAF
• Tagging intended semantics
– See previous
• Higher order and frame based syntax
• Two requirements, moved to RIFRAF
• Consistency with major market technologies
• Too vague, replaced with:
– RIF should accept Relational Tables/Views as data.
(move to data sources e.g. RDF, XML, …)
– Permit SQL queries to be used in rules. (moved to
data sources)
– RIF should accept UML Instances as data. (??? future
discussion)
– RIF should accept ORM Fact Model populations as
data. (??? future discussion)
– RIF should express SBVR business rules (moved to
RIFRAF)
• Meta-data for currency of rules
– RIF will have a notion of when rules apply.
– Isn’t this just a condition on a rule?
– Possibly discuss later with meta-data like
author
• Capability to pass descriptive text through
RIF
• RIF shoudl be able to pass comments
• Meta-data indicating executability of rules
• Needs further discussion
• RIF scope – exchange of RDFS/OWL fact
models
• Add to RDF/OWL data-source discussion
• Four modal operators
• Goes to RIFRAF