Key Information for School Webmasters ------------------------------------- BACKGROUND I'm prompted to write this document to air some concerns and issues arising from my planning for the demise of SAM3. Not only does SAM3 provide an easy and comprehensive way for Schools to manage their non-financial administrative data, but it provides a data source for driving other web-based applications, and import/export service with SITS and IT Sevices User List. These applications include: * All SAM3 Schools student & staff email address lists * SHiPSS Module Templates for the web * SHiPSS Web-based Programme & Module Student Feedback/Assessment * SHiPSS Staff Pages for the web * Proposed SHiPSS web-based Student Module Selection * Geography Web-based Student Module Selection (import to SITS) The Student data management aspect of SAM3 is becoming redundent with the final phase of Schools entering the SITS embrace. Albeit, there may be a reporting function for it in the short term. In time, probably during 2003/4, e:Vision (SITS's web interface/portal) may well be capable of replacing Schools internally developed web applications? For the next 18 months (if e:Vision only fully comes on-stream in Summer 2004/5) Schools are obliged to provide web-based Module Templates and they also have to obtain student feedback on their Programmes and Modules. Small Schools could satisfy these requirements by what one might call clerical methods: static, hand edited web pages for lists of modules and their templates; badgering students to return questionnaires and then hand coding and analysing the results. For large Schools, numbers of students, Programmes and Modules make such exercises very resource hungry and prone to error. I am aware that the SHiPSS webmaster is preparing his student targetted web applications for this sessions use. Chemistry are looking to web enabling their Student feedback exercise. Geography are also about to start preparation for updating their web application for this session. I expect there are other Schools and Departments working on similar web projects. WHAT KEY DATA? Student orientated data: * Lastname (capitalised format) * Initials * Title (Ms,Mrs,Mr,Dr,etc.) * Forenames (capitalised format) * IT Services Username (for authentication) * Email address (IT Services allocated) * Student Number (SPR, e.g. 510012345/2) * Current Programme of Study ID (e.g. UFA3SBEHPS01) * Current Programme of Study Name (e.g. BA Economics and Politics) * Current Year-of-Study (Stage/Level, e.g. 1, 2, 3, 4, etc.) * Graduate Status (e.g. UG, PG, etc.) [could be deduced from ProgID] * Current Status (e.g. Current, Abroad, Interrupted, Debtor, etc.) * Personal Tutor(s) * Student's registered Modules ID's (e.g. BEE1001, POL1003, ...) * Student's registered Modules Names (e.g. Principles of Econ....) * Student's registered Modules Credits (e.g. 30, 15,...) Staff orientated data: * Lastname (capitalised format) * Initials * Title (Ms,Mrs,Mr,Dr,etc.) * Forenames (capitalised format) * IT Services Username (for authentication) * Email address (IT Services allocated) * Staff Number (e.g. P012345) * School/Department (e.g. HPSPOL, etc.) * Category (e.g. Academic, Ac.Related, Clerical, Rec.Teacher, etc.) * Position (e.g. Lecturer, Senior Secretary, HoD, etc.) These lists are a minimum subset of what data could be used by web applications. Some of data fields above could be inferred, e.g. Graduate Status from the Programme ID (U* = Undergraduate). Some data could be looked-up for fairly static, long text string data, e.g. Module Name from Module ID, Programme Name from Programme ID. The majority of these data fields are available in SITS. My hunch is that Administration/IT Services would be loathe to grant access to the Oracle database (that is the datastore for SITS) to School based web application developers. PROPOSALS That the data fields listed above (amended after discusssions with interested parties) be made available for Schools based web developers. That the data is updated by nightly refreshes from the various data sources (mainly SITS). Such refreshing is already common amongst the various Administration systems. I would expect the data to be held in one of two storage methods: * MySQL database on Helios * an extended LDAP source A MySQL database service is made available by IT Services on Helios. LDAP is in use for user authentication, but I understand is currently only configured with usernames and passwords. Both of these interface well with PHP, probably the most commmon scripting environment in use for web applications. It would be possible to develop a PHP function for web developers. It would provide the required data in a useful and usable form but hide the technicalities. AUTHOR: Ray Burnley Thu 13-Feb-2003