Technical Project Proposal
Definition of an European Educational Person (DEEP)
Author: Peter Gietz, DAASI International Ltd.
Since the definition of the first version of the X.500 Directory
standard, the data model for storing information on persons had been an issue.
In X.521 (88) three objectclasses had been defined in this respect: person,
residentialPerson and organizationalPerson. Since the attributes defined in
these objectclasses didn’t fulfil all requirements for storing white pages
information in the directory, additional objectclasses have been defined. One
of the first of these enhancements were defined in the frame of one of the
first X.500 directory pilot projects COSINE (RFC 1274). Other directory
projects defined extra schema elements, e.g. North American Directory Forum or
the EURESCOM projects of European Telcos, which were based on the ITU F.510
White pages Service Definition. In the IETF an RFC on InetOrgPerson was defined
which is widely used in the educational as well as in the commercial realm (RFC
2798). The user-security specification of the Common Information Model, which
is defined inside the industry forum DMTF, is based on inetOrgPerson. Recently
two new person schema definition initiatives have evolved that try to enhance
the inetOrgPerson schema: In the frame of the Internet2 project, a working
group has been established to define the so called EduPerson objectclass. The
other new initiative was installed by the Grid Information Services WG of the
Grid Forum (now Global Grid Forum). It especially aims at the needs of grid
computing facilities, with special problems of distributed resources
(accounting etc.).
TF-LSD was approached by the EduPerson Group as well as by the
GridPerson group for input. It was decided to comments on both respective
texts. In the frame of these discussions the need was felt to have some base
for the decision, what to do about person schema in the European Research
community.
This project is proposing to evaluate all the above mentioned as well as
additional sources. Based on the findings it will either promote one or more of
the existing object classes, or if necessary define the new object class
EducationalPerson that should be used in the European research community.
Although interoperability with similar efforts should be aimed at, the specific
needs of European educational organizations should be taken into account as
well.
3.1. Deliverables
A) Setup of a project Website where all results are to
be published. Discussion of the work will take place on the TF-LSD mailing
list.
B) Survey and evaluation of the requirements and needs
of the European research community in respect to person schema, including
whitepages services, PKI and grid computing. This can only be done in
cooperation with the European NRNs and with some exemplary member
organizations, such as Universities. All NRNs and some member organizations
will be contacted with a questionnaire. The results will be summarized in a
report.
C) All previous work on person schema will be
evaluated and summarized in a report. Although also older texts will be taken
into account, the aim of this report will not be historically, but it will try
to evaluate all work done in respect to the current needs defined in B.
D) Definition of an object class EducationalPerson, if
needed. The data model will try to include current work done in this field,
especially the EduPerson and GridPerson work. This can be done by not defining
overlapping object classes and only defining object classes with attributes not
defined elsewhere. Additionally a hierarchical inheritance model can be defined
in which the attributes of other object classes can be incorporated. Ideally,
the other WGs will agree to such an inheritance model.
E) Development of exemplary prototype applications to
exemplify the ideas of the definitions. This will not be production usable
software, but only a proof of concept. Not all defined attributes have to be
dealt with in the applications. The source code will be published, preferably
under the artistic license (www.opensource.org/licenses/artistic-license.html)
which will allow anyone to develop non-commercial as well as commercial
software based on the prototypes but requires the proper credit to be given to
both project partners.
F) Active cooperation in the EduPerson and GridPerson
WGs, with the aim to represent the European perspective as well as to harmonize
the different approaches. This deliverable is dependent on travelling.
G) Promoting and disseminating the use of the defined
schema in European research organisations, via presentations and articles.
Again this might require additional travel funds.
3.2. Timetables
|
Deliverable |
Description |
In charge |
Starting
month |
Ending
month |
Kind of deliverable |
|
A |
Website |
TERENA |
1 |
12 |
Website |
|
B |
Survey of requirements |
DAASI/TERENA |
2 |
5 |
Questionnaire + report |
|
C |
Survey of previous work |
DAASI |
4 |
7 |
Report |
|
D |
Objectclass definition |
DAASI |
6 |
8 |
Document |
|
E |
Prototype application |
DAASI |
7 |
11 |
Software |
|
F |
Cooperation with other WGs |
DAASI |
1 |
12 |
travel reports |
|
G |
Promotion/dissemination |
DAASI/TERENA |
8 |
12 |
Travel reports + presentations |
3.3. Phases, cut off points
|
Phase |
Description |
deliverables |
Finished by month |
|
1 |
finish preliminary surveys |
B and C |
7 |
|
2 |
finish object class definition |
D |
8 |
|
3 |
finish prototypes and dissemination |
E, F and G |
12 |
|
4 |
Final report |
|
12 |
A bi-monthly progress report will be produced. This
report will be accessible via the project web page. TERENA will provide a
template for this report.
A TERENA Technical Report will be produced with an
evaluation of the definition and usage of the object classes. DAASI will
deliver the contents of this report while TERENA takes care of the marking up.
The draft versions of the deliverables will be
discussed on the TF-LSD mailing list.
The results of this project will help future projects
that implement directory applications which manage person information. DAASI
plans to produce software on basis of the project results, but will not require
additional funding from TERENA.