|
|
|
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
|
|
|
|
|