• Frame-based representation, Inheritance of defaults, Reification

This is one of the possible Use Cases.

1. Abstract

This use case illustrates the need for frame-based representation of information (as opposed to relational, predicate-based, representation); the need for flexible semistructured data support; the need for inheritance of defaults (with overriding); and the need for reification.

2. Status

• Originally proposed by: MichaelKifer

• This use case is a simplified version of an actual system, which was implemented in the FLORA-2 system (http://flora.sourceforge.net)

  • and is used in day-to-day management of the graduate program in the omputer Science Department at Stony Brook University

    (http://cs.stonybrook.edu)

3. Links to Related Use Cases

• Situation_Assessment_and_Adaptation

  • Most of the features listed in requirements 1-4, 6 in that use case can be helped by frame-based representation and the use of

    defaults. The FLORA-2 system (http://flora.sourceforge.net) has most of the features required for the above use case.

• Information_Integration_with_Rules_and_Taxonomies

  • This use case can be helped by frame-based representation of information.

• Enterprise_Information_Integration

  • This use case can be helped by frame-based representation, such as F-logic (http://flora.sourceforge.net/aboutFlogic.php), which is supported by FLORA-2 and is also a key requirement of the current use case.

4. Relationship to OWL/RDF Compatibility

F-logic is an extension of the RDF triple model.

5. Examples of Rule Platforms Supporting this Use Case

• FLORA-2 (http://flora.sourceforge.net/) supports frame-based representation, inheritance, scoped negation, and reification.

6. Benefits of Interchange

• Different parts of the system could be located at different sites (which manage different parts of the information). These different KBs would be able to exchange information and invoke each other's reasoners.

7. Requirements on the RIF

• Support for nonmonotonic inheritance
• Semistructured data
• Support for frames
• Support for reification

8. Breakdown

8.1. Actors and their Goals

• Students
• Admission officers
• Program directors
• Other administrators

8.2. Main Sequence

8.3. Alternate Sequences

9. Narratives

9.1. Unified Student Management System

A unified student management system in a university that offers undergraduate, graduate, and doctoral programs is exceedingly complex. It encompasses admission as well as all stages of the study towards a degree. Different programs have different admission requirements (e.g., they might require different types of documentation) and different policies that govern the course of the study.

For instance, for admission, art departments might require creative work to be submitted and/or interviews. Graduate programs might require (mandatory or optionally) evidence of accomplishments such as completed projects or published papers. Graduate programs might have "proficiency" requirements (evidence that the student has attained knowledge in certain areas of science at the undergraduate level; if not, a student might be required to erase deficiencies in certain areas during their graduate years). PhD programs often require various kinds of special examinations during the course of the study.

Often there are also complex policies for tuition scholarships, graduation requirements, etc. They govern who gets scholarships and at what level; what it takes to graduate; etc. These policies often change over time, but must all be retained and applied in appropriate situations due to "grandfather rules" (a legal concept that states that students who were throughoutunder a certain policy can request to have this policy in effect thoughout their studies even if the policy changes in the interim). This means that such policies will be represented as objects that represent sets of rules (i.e., these objects will reify the rule sets). These rules will not be asserted initially. Instead, different kinds of such rule sets will be temporarily asserted to make inference in one case or another and then retracted.

10. Commentary

• The data is inherently semistructured. Implementing such systems using the relational model (including Prolog-style predicates) is a quagmire. Even if implemented using the relational model, changes in data collection requirements and policies often require costly schema revision. A flexible frame-based representation is called for in such situations.

• This type of systems often require that certain information is inherited from higher-level descriptions, such as classes. For instance, an academic adviser is the student's project or thesis adviser. If a student doesn't have such an adviser, then the academic adviser is inherited by default from an appropriate class description (e.g., a graduate or an undergraduate program director becomes the default adviser).

• To be maintainable, policy rules (such as tuition waiver, graduation requirements) should be reified and represented as time-dependent objects. Depending on a concrete time point and the state of the underlying database at that time, student's eligibility to graduate or to receive tuition scholarship can be validated by fetching the appropriate policy object and then the corresponding policy rules can be applied.