Analyzing Use Cases and Requirements (or What is the RIF?)

Dear RIF-WGers,

First of all, best wishes for a happy new year!

I wanted to clarify and expand on the remarks I made on the conference
call today concerning
the process of analyzing use cases.  I apologize for the length of this
message, but as a co-editor
of the document I feel it is important to not only share my thoughts,
but also explain how I see
them relating to the mission of the WG as stated in the charter. 

Here is a key passage about the UC&R document in the WG charter:

		..."Use Cases and Requirements" document, containing
description and analysis of the rule use cases 
		of interest to Working Group members. Each use case
should be connected with the features/requirements
	      it motivates and the phasing of those features. (SECTION
2.1)

The second sentence in this quote suggests the idea of coming up with a
way of classifying features/requirements
into categories and then using that classification to organize the use
cases, rather than the other way around. 
An advantage of this approach is that it provides a way of getting some
kind of top-level organization on a very large
set of use cases that is daunting to tackle using a bottom-up approach.

Another reason I present this approach is because it helps to focus
attention on the crucial question, What 
exactly is the RIF?  Is the RIF "just" a rule language, albeit one that
provides a well-reasoned standard, or is
the RIF more than that?  And, if so, what is the "more?"

To see why this question arises, consider two key quotes from the
RIF-WG charter.  Here they are:

		This Working Group is chartered to produce a core rule
language plus extensions
	      which together allow rules to be translated between rule
languages and thus transferred
            between rule systems. (ABSTRACT)

		The Working Group is to specify a format for rules, so
they can be used across diverse systems. 
		This format (or language) will function as an
interlingua into which established and new rule 
		languages can be mapped, allowing rules written for one
application to be published, shared, and 
		re-used in other applications and other rule engines.
(SECTION 1)

(It is worth noting that the RIF-WG charter allows for the possibility
of extensions of the core that "need not all be combinable into a
single unified language." (SECTION 1) So even if the RIF standard comes
to be widely adopted, it is likely that different "dialects" of
RIF-based rule languages will emerge and therefore the need for
translation mentioned in the above quotes would still arise.) 

One could argue that the existence of a good core standard with the
right set of extensions should make it possible for anyone
with the appropriate background to figure out how to translate rules
written in one logical paradigm into the standard (and then 
re-translate the result into other logical paradigms). So there is no
need for "more" (at least as concerns translation). But one could also
argue that a good rule standard together with a good standard for
specifying semantics and inference-engine paradigms should make it
possible for such translations to be done by machine according to a
standard. So at least some of the "more" that could be part of the
overall RIF specification is whatever features would be necessary to
enable (some degree of) standard-based mechanized rule translation
either between non-RIF languages and RIF, or between different RIF
dialects.

Looking over the use cases that have been submitted, it seems that a
fair number imply a view of the RIF specification as involving 
something "more" than a rule language.  Not all of these use cases are
stated explicitly in terms of the issue of "translate and transfer,"
but many do talk about properties of rules that would be important to
take into account in attempting to share rules. 
The point is that there is a big difference between a rule-language
feature, e.g., use of classical negation, and a feature that 
allows one to represent or talk ABOUT such features.  The latter are
"metalinguistic" or "meta-level" features, since they are not part
of the rule language as such.   

Based on these considerations, below is a proposed top-level breakdown
of use cases into 3 categories according to the nature of the
requirements they embody: 1) requirements on the rule-language itself,
2) requirements on aspects of the specification that
provide information ABOUT rules (meta-level features), and 3)
requirements on aspects of the specification that relate to enabling
interchange of rules.  In each case I have provided example
requirements that are drawn (or extrapolated) from use cases submitted
on the WIKI.  I have sorted a number of the use cases in the WIKI into
these categories.  Of course, some use cases fall into more than one
category. That is not a problem, since the main goal is to come up with
requirements and the use cases that motivate them, not to classify use
cases into disjoint categories.

The main issue that needs to be addressed is whether the WG endorses
the view of the RIF specification as incorporating metalinguistic
features and interchange-enabling features in addition to rule-language
features.  

THREE CATEGORIES OF REQUIREMENTS 

1) Use Cases that embody or generate requirements for specific
rule-language features in the RIF standard.

    These UCs illustrate how an application depends upon executable
rules having a particular feature.

    Example requirements:
 
               1) The RIF rule language must allow propositions and
rules to have a floating point number
               in the range [0,1] associated with them in some fashion
so that reasoning under
               uncertainty can be accommodated.  

		   2) The RIF rule language must allow rules to be
given labels and allow propositions that express the
               relative priority of two labeled rules to be represented
in some fashion so that complex
               policies or preferences can be handled without making
the bodies of rules overly complex.

		   3) The RIF rule language must allow propositions and
rule elements to refer and/or incorporate 
               pre-existing elements defined in RDF/RDFS, and OWL
documents so that these elements do not need
               to be redefined just for the purpose of being included
in rules.

 2) Use Cases that embody or generate requirements for meta-level
features of the RIF specification

    These UCs illustrate how an application or process depends upon the
ability of systems to share
    information ABOUT the information encoded in rules.
 
    (NOTE: Such features may be seen as being at the "meta-level"
because they do not specify anything about the syntax or 
	     semantics of rules themselves, but instead provide ways of
expressing properties of rules or rule systems.)

    Example requirements:

             
              1) The RIF specification must provide a way to encode the
intended semantic interpretation of a
              set of rules, so that systems based on different logical
paradigms can determine how to best
              represent and use the information contained in the rules.

                1.1) The RIF specification must provide a way for rules
to be classified as belonging to certain categories,
			for example, "deductive," "reactive", etc. (And
the RIF specification must also make it possible to 
			express exactly what is meant by such
categories.) 

		    1.2) The RIF specification must provide a way for
expressing the fact that a rule-set is intended to be used
			in conjunction with a "Closed World
Assumption." (And the RIF specification must also make it possible to 
			express exactly what is meant be such an
assumption.) 
         

  
 3) Use Cases that embody or generate requirements for
interchange-enabling features of the RIF specification

    These UCs illustrate how an application or process depends upon the
ability of systems to share
    rules, where this sharing can be anything from a literal "exchange"
(copying without any changes)
    or something that involves intermediate processing. 

   
	(NOTE: There is clearly a relationship between this category
and category 2: meta-level features that enable sharing 
		 information ABOUT rule properties should make it
easier to interchange rules among diverse rule-systems.  However, as
the
		 examples below illustrate, interchange-enabling
features need not be meta-level features, but can also belong to
		 the rule-language itself.  So why not include these
under category 1?  The reason goes back to the emphasis placed
		 on interchange of rules in the RIF WG charter, which
seems to justify having a separate category for these features.)

	Example requirements:
             
              1) The RIF specification must provide a way for a rule
using scoped features (e.g., scoped negation-as-failure) to 
		  dynamically bind the scope during rule execution
taking account of the local context.

		  2) The RIF specification must provide a way for the
terms in a rule to be linked to corresponding terms in another
              vocabulary (including natural language) in such a way
that an equivalent representation of the rule in the other 
              vocabulary can be constructed from the original rule.

		  3) The RIF specification must provide a way for the
execution of a rule to cause designated remote rule-sets to be 
		  dynamically imported into the current rule-execution
context.
  
 

Allen
 

_______________________________________________________________

Dr. Allen Ginsberg        The MITRE Corporation, Information Semantics 
aginsberg@mitre.org       Center for Innovative Computing & Informatics

Voice: 703-983-1604       7515 Colshire Drive, M/S H305 
Fax:   703-983-1379       McLean, VA 22102-7508, USA

Received on Tuesday, 3 January 2006 22:59:53 UTC