Ben: Scoping the MetaData

Quick introduction of my role
I will be working on structuring and distilling validation outputs for the repository.

QAA documents worth reviewing:

• Programme Specification Pro-Forma (Word)
• Programme Specification Pro-Forma Guidance (Word)

Had a brief meeting with Chris Gray today - an introduction meeting. We discussed the issue of identifying what appropriate meta-data fields should be created/used - based on what attributes (data fields) are collected during the validation process. One issue is the value of this data/information to the user - in respect to the fact that the user will be interested in the whole process of validation - how it was originally submitted, reviewed and then finally approved:

1. Originally submitted documentation (completed against the validation specification)
   
2. The validation report (outline any conditions that need to be addressed for the submission to be successful)
   
3. The amended documentation (to meet the conditions that arose from the validation report)
4. Response to validation conditions report (how successful the faculty was in meeting the conditions)
   

This is a principle of 'traceability' in the change process - tracking where and why amendments were made to the original submission. This needs further discussion and is something that contributes to the 'value' of this project, but not necessarily of concern now, as the primary concern here is to identify the 'key' meta-data.

Key Meta-Data (requirements engineering)
The 'key' meta-data, for the time being, is the top level data about the documents - a good starting point is generic data collected through the Programme Specification Pro-Forma (Word): (the following includes possible additions suggested during the meeting)

1. Teaching Institution (e.g. Staffordshire University, SURF, UK Non-SURF, Overseas)
2. Accreditation / Professional / Statutory Body
3. Final Award (e.g. CertHE, BA, BA (Hons), BSc)
4. Programme Title
5. UCAS Code(s)
6. QAA Subject Benchmarking Group(s)
7. Date of Production (validation)
8. University Faculty / School
9. Mode of Attendance / Delivery Method (e.g. PT. FT)
10. Method of Delivery (e.g. Blended, Distance)
11. THESIS / Award code
    

Most of these are currently being recorded by QA in a database (could be exported in CSV file to accompany the documentation). This 'key' meta-data is useful for tracking down the documents that match what a user is looking for. However, as mention above, further discussions are required (possibly through steering group) to ascertain what further meta-data fields need to be created to record some valuable data about specific validation processing cases, which would indicate best practice to the user. * N.B. this offers another question about whether unsuccessful validations should be included - see Response to validation conditions report .

Recording Best Practice (eLearning Models)
This is an important part of the project and further discussions are required to establish what meta-data field(s) are required to disclose the type of eLearning model(s) that were used to inform the validation process - critical when looking at creating a 'fast-track' approach for courses that engage with technology supported learning (TSL).

Next steps

• Need to contact Sam Rowley / Ray Reid about Hive Repository Meta-data (technical queries) - specifically, searching for documents (inc. listing all documents that relate to each other) and XML Meta-data templates
• Further meeting to be arranged with Helen Walmsley about project requirements and direction of scoping this part of the project - in regard to what outputs are relevant and useful/ of value
  
• Investigate Meta-data standards further - in respect to library systems / university QAA systems

Hope this has proved useful - Ben.