PAPI Survey 
 
 
  
Overview
Student records contain two types of information: personal information about the student, and performance information that relates to the student's history, current work, and future objectives. This specification is very general: it may be implemented in a variety of operating environments and application. 

The purpose of PAPI systems is (1) to represent student records, and (2) to communicate this information with other applications. PAPI records shall be the same across all syntax bindings and encoding representations. In other words, the choice of syntax binding or encoding representation is for the convenience of the application and its environment. Applications code information for the following reasons: 

  1. For internal use to handle "version problem" for applications, e.g., software upgrades can have same student record database.  

  2. For internal use to save/restore state for applications that stop and start again, i.e., data will be kept externally.  

  3.To interchange with other applications, i.e., a common interchange format.  

A common question is: is PAPI a protocol, a database format, or something else? To be precise, PAPI specifies data interchange formats, i.e., a representation of information in some encoding. The PAPI specification is not a protocol, but could be used as a basis for a data communications protocol (other information, flow, and processing would be described to fully define the protocol). The PAPI specification is not a database format (PAPI alone is ineffecient for database organization), but PAPI could be used to import data to and/or export data from a database. 

PAPI Information coding describes the overall organization of the internal structures. Personal and performance information is:  

  1. Organized into records. Each record represents a unit of information with respect to the student.  
  2. Records comprised of fields. Each records contains fields. Each field my be of a certain, predefined, type of the field may be a records itself.  
  3. Fields may be untagged (identified by "next", "previous", or "Nth") or tagged with a "name".  
  4. Field tags may be internal, external, or implicit. Internal tags have their name embedded within the contents of a field. External tags have theirs names external to the field, usually, contained within     the administrative information associated with the record. Implicit tagging occurs when there is prior agreement on the structure and ordering of a record, such as "student-name" is the name of the first field, and "address" is the name of the second field.  

When information is conveyed with certain semantics, the information is transformed to and from an external form according to a syntax. The  syntax may be multipurpose and general, serving applications other than PAPI applications. Likewise, PAPI can use several different syntaxes to convey the same information and semantics. The syntax binding describes how semantics are mapped into a particular syntax and vice versa.

The current open issues in PAPI  specifications are Interoperability Negotiation, Agreement on Semantic Codings, Other Syntax Bindings.

PAPI vs. Grading System  
 
Although PAPI specifications aimed to provide a universal structure of portable student records, the current situation is far from using a standard.  Specifications are a collection of suggestions. Therefore, it is hard to obey non-existing PAPI standards in a specific implementation, which requires exact syntaxes and structures. On the other hand, some ideas of PAPI are kept in mind while implementing Grading System. The basic logic of PAPI is not so complicated and easy to implement. The only thing need to be done to produce a PAPI compatible product is waiting for the complete standards. 

To provide possible upgrading of the system to PAPI standards in the future, some design issues are considered. Like specified in the PAPI, and also as a natural sense, student records and performance records are constructed in different tables in the database by sacrifying from the performance. Since PAPI is not a database format, internal representation of tables are currently independent from the PAPI, but appropriate to convert to a PAPI student record and performance record.  

The problems of PAPI and Grading System integration is that both system has different kind of data types necessary besides their  common points. For example, Grading System does not require some student record informations like parent names,  telephone numbers, student addresses, etc. In fact, student information in the Grading System is just a subset of a student record in a possible university to identify student and to store system's specialized student data like url, login-id, email, etc. In a possible future complete system including PAPI specifications, the student records of Grading System can be taken from a central database, of a Web University, for grading operations through the PAPI interface. Like the differences of PAPI student records, Grading System  itself contains some necessary specialized informations like course information, assignment informations, grading strategies,  surveys, etc. Since PAPI only consider student and its performance records, those kind of information are left to applications. In that sense, PAPI just seems like final report format of student activities from one system to the other. 

When we think about the integration of PAPI and the Grading System at the implementation level for the future, some interface modules, (packages in PL/SQL) should be written to fetch the student and performance records from the database. As a current situation, it does not seem to be hard to convert Grading System's database table records to PAPI format. Any application other than Grading System can reach NPAC student and performance records through this interface, as long as security issues are solved.  

We can say that the internal representation of Grading System records are already in agreement with the PAPI, which is necessary for the future versions of the Grading System according to the PAPI.  As specified by PAPI, modules that only need performance information  have access to performance information, or modules that only need student personal information  have access to personal information. 

 In PAPI specifications, it is specified that when two systems interoperate, they need to determine and resolve incompatibilities in their data model. Again, for  a possible future PAPI application which requires interaction with the Grading System, similar adaptors can be written to interchange records between applications.
 

References  
Personal and Performance Information (PAPI) Specification1997-10-09

[home] [back]