User Tools

Site Tools


middleware:devel:ed:docs:jobs-degrees

Jobs and Degrees Schema Extensions

Author David Hawes
Date 2007/01/04

(draft)

Introduction

The student and employee data that currently resides in the Registry is incomplete and does not reflect all the data that is contained in Banner. As a result, users of the Enterprise Directory cannot lookup, search on, or authorize users on student and employee data that may be of use for their applications. This document will identify the data that should be in the Registry and outline both Registry and ED-LDAP schemas to better reflect student and employee records. The goal is to have as much data as possible about students and employees in the Registry.

Current Registry Data

Student Data

The Registry tables VTSTUDENT, VTSTUDENT_DEGREES, and VTSTUDENT_MAJORS contain all the data about a student in the Registry. VTSTUDENT contains current student information about a person, such as the campus they are taking classes at, their academic level, and last and next terms of enrollment. VTSTUDENT_DEGREES contains information about a degree that has been awarded, including the major and academic level. VTSTUDENT_MAJORS contains the majors that correspond to the data in VTSTUDENT.

The primary problem with the VTSTUDENT table is that it contains data that is merely a snapshot of either the last degree completed or the last major in progress. This data should be contained in other tables and only generic student data should be kept. We will go over this in more detail when we discuss the schema in later sections.

The primary problem with the VTSTUDENT_DEGREES table is that it simply has too little data. There should be dates such as degree started (first enrolled term) and degree completed, as well as many of the attributes contained in VTSTUDENT, such as campus, college, and department. Basically, we need all the data we can get about degrees to be reflected in the Registry.

VTSTUDENT_MAJORS suffers from almost exactly the same problems as VTSTUDENT_DEGREES, namely that there is a paucity of data. It should contain much more data than it does, and this data should be all the information about a major we can get. Almost certainly a melding of tables will need to take place to reflect all of this data in a sane way. Of course, this will be discussed when we take a closer look at the schemas. We also do not have multiple majors in this table, which makes it difficult to authorize people on major if they are a double major. This should definitely be rectified as soon as possible. To reiterate, we need as much data as we can get from Banner.

We should also replicate information about minors and reflect this data in the Registry.

There should be a discussion about the naming conventions used so we can collect and store student data correctly. It seems that VTSTUDENT_DEGREES are only completed, but I believe that it makes sense that a degree can be incomplete. In brief, it seems like DEGREES encapsulate MAJORS, and there should be a flag or a date that signifies completion of the degree. This makes the data easier to represent in the Registry and ED-LDAP and it also makes it more extensible. If there is some kind of naming convention that this defies, we need to discuss it.

Employee Data

Employee data should be extended to include job history. The main shortcoming of employee data is that all of the attributes in the Registry aren't reflected in ED-LDAP. Once we do this and add more data from Banner, it should be quite complete.

Discussion of Degrees and Majors

ou=Degrees Schema

In an effort to keep as much student data about a person in ED-LDAP, I am proposing a new branch that will contain entries that encapsulate all the information about a student in the Enterprise Directory. This branch, ou=Degrees,dc=vt,dc=edu, will contain entries of the objectclass virginiaTechDegree, which will be defined below. The relationship between the ou=Degrees,dc=vt,dc=edu entries and the virginiaTechPerson entries will also be discussed.

Current Schema

The following attributes represent student data in ED-LDAP:

All of these attributes are defined in the virginiaTechPerson objectclass.

Proposed Schema

The following outlines the virginiaTechDegree objectclass. Entries of this objectclass will reside in ou=Degrees.

Note: The following schema is under construction and will likely change.

objectclass virginiaTechDegree

superior: top
required: uudid
optional: academicLevel
academicLevelCode
advisor
bannerAcademicLevel
bannerAcademicLevelCode
campus
college
collegeCode
degree
degreeCode
degreeAwardedDate
degreeType
degreeTypeCode
firstEnrollmentTerm
firstEnrollmentTermCode
generalAcademicLevel
generalAcademicLevelCode
lastEnrollmentTerm
lastEnrollmentTermCode
major
majorCode
minor
minorCode
nextEnrollmentTerm
nextEnrollmentTermCode
undergraduateLevel
undergraduateLevelCode

uudid

Required: Yes
# of values: single
Definition: The universally unique degree identifier for this degree.
Notes: The uudid corresponds to the degree sequence number in the Registry.
Example: uudid: 1

academicLevel

Required: no
# of values: single
Definition:
Notes: We need to determine the difference between academicLevel(s), bannerAcademicLevel(s), and degreeType(s) before we can define this attribute. This attribute may be superfluous or unnecessary.
Example:

academicLevelCode

Required: no
# of values: single
Definition: The academic level that corresponds to this degree.
Notes: We need to determine the difference between academicLevel(s), bannerAcademicLevel(s), and degreeType(s) before we can define this attribute. This attribute may be superfluous or unnecessary.
Example:

advisor

Required: no
# of values: single
Definition: The DN that is the advisor of this degree.
Notes: Must be in DN format.
Example: advisor: uid=123456,ou=People,dc=vt,dc=edu

bannerAcademicLevel

Required: no
# of values: single
Definition: The academic level according to Banner.
Notes: We need to determine the difference between academicLevel(s), bannerAcademicLevel(s), and degreeType(s) before we can define this attribute. This attribute may be superfluous or unnecessary.
Example:

bannerAcademicLevelCode

Required: no
# of values: single
Definition: The academic level code according to Banner.
Notes: We need to determine the difference between academicLevel(s), bannerAcademicLevel(s), and degreeType(s) before we can define this attribute. This attribute may be superfluous or unnecessary.
Example:

campus

Required: no
# of values: single
Definition: The name of the campus this person is currently affiliated with. For instance the campus a student is attending, or the campus at which a staff member works.
Notes: This field will have a controlled vocabulary however it has not yet been determined.
Example: campus: NoVA

college

Required: no
# of values: single
Definition: The college that corresponds to this degree.
Notes:
Example: college: Engineering

collegeCode

Required: no
# of values: single
Definition: The college code that corresponds to this degree.
Notes:
Example: collegeCode: 05

degree

Required: no
# of values: single
Definition: The awarded degree.
Notes:
Example: degree: Bachelor of Science

degreeCode

Required: no
# of values: single
Definition: The awarded degree.
Notes:
Example: degreeCode: BS

degreeAwardedDate

Required: no
# of values: single
Definition: The date the degree was awarded.
Notes: ISO8601 complete data w/ hours, minutes, and seconds. Time is 24 hour based. Format is yyyy-mm-ddThh:mm:ssTZD TZD = Time Zone Designator. For the Eastern Time zone this is –0500
Example: degreeAwardedDate: 2001-11-09T15:25:15-0500

degreeType

Required: no
# of values: single
Definition: The type of degree a student is seeking.
Notes: This attribute will only have a value for people who have an affiliation type of student. This attribute has the following controlled vocabulary: bachelor, masters, doctorate, vetmed.
Example: degreeType: bachelor

degreeTypeCode

Required: no
# of values: single
Definition: The code that is the type of degree a student is seeking.
Notes: The vocabulary is TBD.
Example:

firstEnrollmentTerm

Required: no
# of values: single
Definition: The first term the student is enrolled for this degree.
Notes:
Example: firstEnrollmentTerm: Fall Semester 2004

firstEnrollmentTermCode

Required: no
# of values: single
Definition: The code of the first term a student is enrolled for this degree.
Notes: The values in this attribute are of the following syntax YYYYMM where YYYY is the 4 digit year this person last attended class and MM is the 2 digit month that term start.
Example: firstEnrollmentTermCode: 200101

generalAcademicLevel

Required: no
# of values:
Definition:
Notes:
Example:

generalAcademicLevelCode

Required: no
# of values:
Definition:
Notes:
Example:

lastEnrollmentTerm

Required: no
# of values: single
Definition: Human readable form of the last academic term a student was enrolled in.
Notes: Only people with an affiliation of student will have a value in this attribute.
Example: lastEnrollmentTerm: Fall Semester 2004

lastEnrollmentTermCode

Required: no
# of values: single
Definition: The last academic term a student was enrolled in.
Notes: Only people with an affiliation of student will have a value in this attribute. The values in this attribute are of the following syntax YYYYMM where YYYY is the 4 digit year this person last attended class and MM is the 2 digit month that term start.
Example: lastEnrollmentTermCode: 200101

major

Required: no
# of values: multi
Definition: The academic major of this person.
Notes: This attribute is only populated if this person has a student affiliation.
Example: major: computer science

majorCode

Required: no
# of values: multi
Definition: The academic major code of this person.
Notes: This attribute is only populated if this person has a student affiliation.
Example: major: CS

minor

Required: no
# of values: multi
Definition: An academic minor for this degree.
Notes:
Example: minor: Computer Science

minorCode

Required: no
# of values: multi
Definition: An academic minor for this degree
Notes:
Example: minorCode: MATH

nextEnrollmentTerm

Required: no
# of values: single
Definition: The human readable form of the next academic term a student is enrolled in.
Notes: Only people with an affiliation of student will have a value in this attribute.
Example: nextEnrollmentTerm: Fall Semester 2004

nextEnrollmentTermCode

Required: no
# of values: single
Definition: The next academic term a student is enrolled in.
Notes: Only people with an affiliation of student will have a value in this attribute. The values in this attribute are of the following syntax YYYYMM where YYYY is the 4 digit year this person last attended class and MM is the 2 digit month that term start.
Example: nextEnrollmentTerm: 200301

undergraduateLevel

Required: no
# of values: single
Definition: The current grade level of an undergraduate student.
Notes: Only a person will only have a value in this attribute if they have an affiliaiton type of student and a degree type of bachelor. This attribute has the following controlled vocabulary: freshmen, sophomore, junior, senior.
Example: undergraduateLevel: junior

undergraduateLevelCode

Required: no
# of values: single
Definition: The current grade level code of an undergraduate student.
Notes:
Example: undergraduateLevelCode: JR

Relationship to virginiaTechPerson Entries

The attributes listed above under “Current Schema” will likely remain the same in virginiaTechPerson entries, though we need to determine what they mean in the objectclass. It seems to make the most sense to have them reflect the latest degree (by date) attempted.

ou=Jobs Schema

Current Schema

Proposed Schema

Registry Schema

middleware/devel/ed/docs/jobs-degrees.txt · Last modified: 2015/06/01 12:02 (external edit)