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.

(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