EUCLID Interoperability
The following table itemizes local processes. Where they are marked
YES in the
EUCLID column this indicates that we believe EUCLID will provide some kind of equivalent functionality for them, even if not identical, and for us to continue locally would be considered by the EUCLID board to be duplication.
Where they are marked
NO in the
EUCLID column this indicates that we believe EUCLID will NOT provide any
kind of equivalent functionality for them and the EUCLID board would NOT consider it to be duplication if continued locally. Changes since the recent reduction in the scope of the EUCLID project are highlighted in
red.
Process |
EUCLID |
Local |
EUCLIDiE |
ITO Reports, Lists and manually initiated Mail Shots (via genrep) |
YES NO |
YES |
NO |
IGS Reports, Lists and manually initiated Mail Shots (via genrep) |
YES |
NO |
NO |
ITO Marks Entry/Return Sheets (via genrep) |
YES NO |
YES |
NO |
Student Transcripts (via genrep) |
YES |
NO |
NO |
Board of Examiners Reports (via genrep) |
YES NO |
YES |
NO |
ITO automatically generated Web Pages |
YES NO |
YES |
NO |
IGS automatically generated Web Pages |
YES |
NO |
NO |
MSc/!PhD Applications automatically generated Mail Shots |
NO |
YES |
YES |
XML MSc Applications automatically generated Mail Shot |
NO |
NO |
NO |
Course Registration Web Form |
YES NO |
YES |
NO |
Course List Web Pages (Roland Ibbett system) |
YES |
NO |
NO |
Teaching Software Management - managing local software for our courses (1)/(2) |
NO |
YES |
YES |
Account Management - logins and account creation on our machines (1) |
NO |
YES |
YES |
Roles and Capabilities Management - groups and authorization on our machines (1) |
NO |
YES |
YES |
Electronic Submission - online practical submission (2) |
NO |
YES |
YES |
Student Mailing Lists (3) |
NO |
YES |
YES |
MSc/Phd Thesis Submission/Archival - online copies of student theses (4) |
NO |
YES |
NO |
UG4 Projects Database - for students and academic staff to manage projects (5) |
NO |
YES |
YES |
MSc Projects Database - for students and academic staff to manage projects (5) |
NO |
YES |
YES |
(1) BJ says this is probably managed by SITS' distribition of the
information (for access by 'machines' and the like) through
existing (adapted) processes e.g. IDMS.
(2) BJ says this is probably within 'direct' interoperability.
(3) The board may consider the above duplication, but not clear whether
EUCLID will provide an equivalent student/lecturer communication forum?
(4) The board may consider the above duplication, but not clear whether
EUCLID will support this? Potentially this may in the future
be done through ERA?
(5) These are currently standalone systems and do not take information from
the school database.
First Meeting
Meeting with Anna, Neil, Tim and Jane Harris (EUCLID facilitator) on Thursday 9th August.
By January 2008 the EUCLID team should have established what is needed to interface
with existing School and College systems that are not duplicating functionality.
Rather than lots of separate setups they would prefer to create one (or a very few)
that encompass the superset of all the data required. This would be defined by about
February 2008 for completion and live testing by August 2008.
Where possible however data for Schools and Colleges would be derived through other
subsidiary systems (such as IDMS and SITS) rather than them defining another interface
directly to EUCLID.
We will produce a superset of the data we would expect to need to continue running
local systems we have that are not duplicating functionality.
We may need to provide formal justification to the EUCLID project board to continue
our local systems although it did not seem likely that there would be objection to
the particular systems we had discussed (unlikely to be provided by EUCLID).
Other issues not related particularly to interoperability were identified during
discussion but are not recorded here.
Data Super Set
This is a description of core data required to drive our processes that are
additional to EUCLID. In principle this should cover everything needed to
continue local teaching software management, account management, roles and
capabilities management and electronic submission.
Course Data
For each course taught by the School of Informatics and for each course
that a student is taking who is registered onto a Programme of Study
within the School of Informatics the following data is required:
- course key - a unique key code for the course, probably current WISARD 'Course Code'
- course semester - a number indicating whether the course is taught in semester 1 or semester 2
- course title - full title for the course, probably the current WISARD 'Course Name'
- course abbreviation - human readable abbreviation for the course, derivable from current WISARD 'School Acronym for Course', eg. INF-AV-4
- (course count) - number of students taking the course (live, not withdrawn or with other exit status). This is optional because such data could be derived locally given a count of students on a particular course from data below.
- (credit level) - 7, 8, 9, 10 or 11, not directly needed but may be necessary to do some local derivation
- credit points - The credit points for the course.
- course year - The normal year the course is taken
For each course defined above the following data on the lecturers teaching it is required:
- lecturer key - unique identifying key for lecturer (staff# or UUN, preferably the latter)
- lecturer firstname
- lecturer surname
- lecturer email - email address(es) for the lecturer
Note that more than one lecturer can be teaching a course. Also note that
in some cases a course has administration staff instead of lecturing staff,
eg.
irr and
irp, and this will need to be represented in EUCLID and
included on the data set above.
For each course defined above the following data on the practical assignments making up
the course work assessment is required:
- course work key - unique id for specific piece of work on course, if not human usable then also need a course work abbreviation
- (course work title) - optional, full title of piece of assessment
Note that each course variation (level), eg.
ads,
ads-v,
adbs-4,
adbs-5 is treated as a different course and often has different numbers
of assignments eg.
adbs-4 has two,
adbs-5 has three.
Student Data
For each student taking a Programme of Study offered by
the School of Informatics or taking a course taught by the
School of Informatics (even if registered on a Programme
of Study in another School or as a visitor) the following
data is required:
- student key - unique id for student (matric or UUN, sMATRIC)
- student enrolment# - matriculation number
- student lastname
- student firstname
- student nickname - informal first name
- (student gender) - Needed for generating email list for female Informatics staff and students
- student UID - official UID (this is derived separately from a central IS service, so not directly from EUCLID, but there must clearly be a common key between EUCLID data and the UID data reflected in student key)
- student emails - comma separated list of email addresses
- student username - UUN
- student pos key - unique id for Programme of Study being taken (probably WISARD 'Programme of Study Sought Code', Annnn code)
- student pos start date - Start date of the student on this programme of study.
- student year - year of study - 1st, 2nd, 3rd, 4th, (MSc, PhD), the latter two can be derived from student pos key
For each student above details on courses taken are required. This can
simply be a
course key list (course included only if student is non-withdrawn
and active). Alternatively full data (including
course key) on
all course registrations with suitable status indication. In addition,
for each course a student is registered on, data on the tutorial group they
are in on that course is required. This can simply be a
tutorial group key
which is a unique (human readable) key identifying the tutorial group.
This is necessary as electronic submissions are organized by tutorial
group - the tutor/marker only sees by default the submissions for
their own tutorial groups and student submissions are automatically
placed into the right tutorial group areas for each course based on
which tutorial group they are a member of.
Additionally since students (MSc and PhD) can tutor and act as demonstrators
(also including UG4) it is important they get the appropriate role and
access locally. To achieve this a student must be flagged as a
Tutor,
Demonstrator or
Teaching Assistant in a separate
teaching role data
field associated with each course they assist on. A student could hold more than one role on more than
one course.
Internally we map students into years. This can be derived locally
from
student year and
student pos key. For example, someone doing a Computer Science
degree in 3rd year would be in the
cs3 and
ug3 years. Hence
we do not need this representation from the EUCLID data stream.
A course is associated with more than one year, based on level.
Years are used for electronic submission to ensure that submissions
for a course that is taught in multiple years go in the right bucket
for the marker.
Complications
For at least some data we need to see the current session data as well as
the previous sessions data concurrently, because of the particular times
of year some of our processes apply. For example, for teaching software
management prioritization is driven by the number of students taking
particular courses in the previous session.
This could be achieved by either adding a
Session Key to the data source
stream and including data on multiple sessions in the one stream, or by
having two separate data source streams one for the current
session and one for the previous session. There is an argument for having
a third stream to reflect the next session as well.
For students there is a requirement to have data on new/upcoming students
in advance of matriculation (before they actually start). This is to
allow creation of accounts in advance of arrival. There is also a
requirement to access old (left) students for handling account deletion
processes correctly. Hence the data stream must provide information on
more students than just those registered onto the current session.
It is of course essential that the data described here can be retrieved
in an automated and unattended fashion. A daily download would be
sufficient for our purposes. The exact manner of access and format of
the data can be flexible.
IS Sources
Account management and Roles/Capabilities management use additional data
sources currently provided from IS. Each of these data sources is based
on current central student data and must be preserved in some way after
the transition to EUCLID. Whether the information they provide is added
to the EUCLID data stream described here or whether the IS services are
continued as-is with a replaced back-end that interfaces to EUCLID does
not really matter to us. Sources described below.
- IS UID Server - we pass matriculation# and surname to server and get back Unix UID and full student name
- IS UID Web Server - similar to above but additionally returns staff UIDs, at: https://www.ease.ed.ac.uk/uid/lookup.cgi?uun=*UUN*
- IS SMS LDAP Server - at smsdir.ed.ac.uk, used to get mailbox for a student, key'd on matriculation number
--
TimColles - 19 Jul 2007