|
Please wait ......
LTSC PAPI - Overview
Terms of use
X
Terms of use
These contents have been obtained from the IEEE LTSC web site and edited for presentation. Please refer to the IEEE LTSC web site for additional information on terms of use.
Print
Important note
This specification was developed by the IEEE Learning Technology Standardization Committee(LTSC) (http://www.ieeeltsc.org). At the 2001-12 IEEE LTSC 1484.2 meeting, the LTSC working group agreed to move the work from LTSC to SC36. The cover letter that transfers the documents (SC36/N0175-N0186) is in SC36/N0174. The working group involved in its development was the P1484.2.
All the information under Learner Information>LTSC PAPI makes up what the LTSC had been calling a proposed standard for Personal And Private Information (PAPI). This work was submitted as technical contributions to be used by WG3. The intent is that this work be continued in WG3 where the IEE LTSC believes there are more resources available than were present in the IEEE WG. The LTSC WG has been dissolved and the work will not go on in the LTSC |
Scope
IEEE LTSC
|
The LTSC Public and Private Information (PAPI) specification is devoted to support the exchange of learner data between different systems. It specifies both the syntax and semantics of a 'Learner Model,' which will characterize a learner and his or her knowledge/abilities. The complete name of this specifications is: "Standard for Information Technology – Public and Private Information (PAPI) for Learners (PAPI Learner)".
The first version of this specification was published in 1997. The last version is draft number 8 issued on November 2001. In this situation, it is an unapproved draft of a proposed IEEE-SA Standard. As such, the specification is subject to change. |
Purpose
The original purpose of the disolved IEEE WG was:- To enable learners (students or knowledge workers) of any age, background, location, means, or school/work situation to create and build a personal Learner Model, based on a national standard, which they can utilize throughout their education and work life.
- To enable courseware developers to develop materials that will provide more personalized and effective instruction.
- To provide educational researchers with a standardized and growing source of data.
- To provide a foundation for the development of additional educational standards, and to do so from a student-centered learning focus.
- To provide architectural guidance to education system designers.
|
Terms of use
X
These contents have been obtained from the IEEE LTSC web site and edited for presentation. Please refer to the IEEE LTSC web site for additional information on terms of use.
Print
| The PAPI Learner Standard describes a particular subset of all possible types of learner information. Learner information is considered a subset of general information about learning technology. In the last edition of the PAPI Learner Standard there were six information types. |
Learner Information Groups in the PAPI Learner Model
|
|
For each of the information types, the PAPI Learner Standard has described a subset that is useful and can be widely implemented. The following is a brief description of the information types:- Learner Contact Information is primarily related to administration.
- Learner Relations Information is about the learner's relationship to other users of learning technology systems, such as teachers, proctors, and other learners.
- Learner Security Information is about the learner's security credentials, such as: passwords, challenge/responses, private keys, public keys, biometrics
- Learner Preference Information describes preferences that may improve human-computer interactions.
- Learner Performance Information relates to the learner's history, current work, or future objectives and is created and used by learning technology components to provide improved or optimized learning experiences.
- Learner Portfolio Information is a representative collection of a learner's works or references to them that is intended for illustration and justification of his/her abilities and achievements.
|
Terms of use
X
These contents have been obtained from the IEEE LTSC web site and edited for presentation. Please refer to the IEEE LTSC web site for additional information on terms of use.
Print
General Information
Title: “Draft Standard for Learning Technology – Public and Private Information (PAPI) for Learners (PAPI Learner)”
Version: 8.00
Release Date: 25 November 2001
Status: Draft
Editor: Frank Farance (Technical Editor)
PAPI is a deprecated specification. Online information is not available |
Draft 8 of the PAPI Learner Standard comprised of 12 parts (Parts 1-6 and Parts 21-26):- IEEE P1484.2.1, Core Features: The main data model and references to other standards
- IEEE P1484.2.2, Rationale: An explanation of important decisions during the development of this Standard
- IEEE P1484.2.3, Learner Information Security Issues: Information and recommendations on important security issues for implementations
- IEEE P1484.2.4, Examples and Illustrations: Information for implementers
- IEEE P1484.2.5, Registration Authority Process: How data elements, value space, coding schemes, code sets, etc. are registered
- IEEE P1484.2.6, Data Element Registry: The registry of data elements, value space, coding schemes, code sets, etc.
- IEEE P1484.2.21, Learner Contact Information: e.g., name, postal address, telephone number, etc.
- IEEE P1484.2.22, Learner Relations Information: e.g., classmates, teammates, mentors, etc. (MS-Word PDF)
- IEEE P1484.2.23, Learner Security Information: e.g., public keys, private keys, credentials, etc.
- IEEE P1484.2.24, Learner Preference Information: e.g., as useful and unusable I/O devices, learning styles, physical limitations, etc.
- IEEE P1484.2.25, Learner Performance Information: e.g., grades, interim reports, log books, etc.
- IEEE P1484.2.26, Learner Portfolio Information: e.g., accomplishments and works, etc.
|
Tracking of Changes:
PAPI Learner Document Parts
|
After reviewing Draft 7, the LTSC 1484.2 working group decided to divide the specification into smaller pieces so that it was easier for conforming systems to describe which portions of the PAPI Learner information they conformed to. The learner information in Draft 7 was split into seven pieces in Draft 8: common data types (Part 1) and six information types (Parts 21-26). Other informative portions of Draft 7 were split off into rationale (Part 2), security notes (Part 3), and examples and illustrations (Part 4). In Draft 7, portions of the learner information datatypes (in particular, certain state and enumerated datatypes) were extracted and defined in a registry (Part 6), as administered by a registration authority (Part 5). |
Terms of use
X
These contents have been obtained from the IMS web site and edited for presentation. Please refer to the IMS web site for additional information on terms of use.
Print
There are 7 previous versions (drafts) of this specification.
New information groups were added during the development of the different versions. |
Terms of use
X
These contents have been obtained from the IEEE LTSC web site and edited for presentation. Please refer to the IEEE LTSC web site for additional information on terms of use.
Print
At the 2001-12 IEEE LTSC P1484.2 working group agreed to move the work (Draft 8) to the ISO/IEC JTC1 SC36 WG3 involved in the definition of an information model for learners.
Learner Contact Information references the vCard standard that supports the exchange of personal information typically found on a traditional business card. |
Terms of use
X
These contents have been obtained from the IEEE LTSC web site and edited for presentation. Please refer to the IEEE LTSC web site for additional information on terms of use.
Print
The PAPI Learner Standard describes four types of obligation attributes for data elements: mandatory, optional, conditional, and extended:- Mandatory data elements are always required for the data structure to be valid. An implementation that does not support or include one or more mandatory data elements is a non-conforming implementation.
- Optional data elements are permitted, but not required, for the data structure to be valid. An implementation that does not support one or more optional data elements is a non-conforming implementation.
- Conditional data elements are required, but their requirement is dependent upon certain conditions. An implementation that does not support one or more conditional data elements is a non-conforming implementation.
- Extended data elements are not permitted within strictly conforming implementations. Extended data elements are permitted within conforming implementations to the extent that the implementation individually supports each extended data element. Extensions are motivated by needs of users, vendors, institutions, and industries (1) that are not directly specified by the PAPI Learner Standard, (2) that are specified and agreed to outside the PAPI Learner Standard, and (3) that may serve as trial usage for future editions of the PAPI Learner Standard.
|
| There two flawors of conformance implementations: "Strictly conforming" and "conforming". They are necessary to address the simultaneous needs for interoperability and extensions. |
Strictly Conforming Implementations
A Strictly Conforming implementation:- shall support all mandatory and optional data elements;
- shall not use, test, access, or probe for any extension features or extended data elements;
- shall not exceed limits or smallest permitted maximum values specified by this Standard; and
- shall not interpret or generate data elements that are dependent on any unspecified, undefined, implementation-defined, or locale-specific behavior.
|
| NOTE — The use of extension features or extended data elements is undefined behavior. |
Conforming Implementations
A Conforming implementation:- shall support all mandatory and optional data elements;
- may use, test, access, or probe for extension features or extended data elements, as permitted by the implementation and data interchange participants, as long as the meaning and behavior of strictly conforming implementations is unchanged;
- shall not support or use extension features or extended data elements that change the meaning or behavior of strictly conforming implementations;
- may exceed limits or smallest permitted maximum values specified by this Standard, and to the extent permitted by the implementation; and
- may interpret or generate data elements that are dependent on implementation-defined, locale-specific, or unspecified behavior.
|
NOTE 1 — The use of extension features or extended data elements is undefined behavior.
NOTE 2 — All strictly conforming implementations are also conforming implementations.
NOTE 3 — An implementation does not conform to this Standard if it redefines Standard features via extension methods, and these features change the meaning or behavior of strictly conforming implementations |
Non-Conforming Implementations
A Non Conforming implementation is an implementation that does not conform to this Standard (either strictly conforming or merely conforming). |
|