Ben: Mapping the MetaData

Useful ref: Using Dublin Core Scheme (some examples of what data to enter)

Aggregation of elements by purpose:

Content: Coverage, Description, Type, Relation, Source, Subject & Title

Intellectual Property: Contributor, Creator, Publisher & Rights

Instantiation: Date, Format, Identifier & Language

Graphical version of mapping (possible matches):

Possible MetaData Limitations in HIVE

After some extensive research and testing in HIVE, it appears that there might be an issue in trying to 'ask' HIVE to acknowledge that a document (object) is part of a collection of objects - the idea of a validation document being part of a larger validation process.

The principle issue (which may still be resolved) is that you can use metadata fields such as 'relate' (Dublin Core DC scheme) to establish a link between documents (relationship), but when you search for a document, HIVE has no facility to represent this relationship to the user - insofar as there is not a 'plus' sign logo that enlightens the user to other related documents (that are related but they might not have directly searched for).

The 'relate' (DC) should allow the reference between documents using terms such as 'ispartof' 'isrelatedto' - A reference to a related resource.

So to clarify - you can reference other documents but with no facility to represent this relationship (only an alphabetized list is produced) - you will only know of this relationship if you were the one that created it and searched for it through the metadata search facility.

I will endeavor to ascertain whether this situation can be resolved in the future as I am currently using a HIVE test server.

In the time being, I will continue to look at mapping the required document metadata to established metadata standards schema used by HIVE.

OAI Dublin Core MetaData Scoping

Link: http://dublincore.org/documents/dces/

A 'simpler' scheme in HIVE for inputting metadata as it uses only 15 elements with no sub divisional elements.

May be worth pursuing - the following useful elements exist:

1.0 Title Automatically populate field with "Item's Title" in HIVE
2.0 Creator
3.0 Subject and Keywords
4.0 Description Automatically populate field with "Item's Description" in HIVE
5.0 Publisher Automatically populate field with "BEGIN:VCARD\nFN:Name of Item's Author\nEND:VCARD" in HIVE
6.0 Contributor
7.0 Date Automatically populate field with "Item's Date of Publication" in HIVE
8.0 Resource Type
9.0 Format Automatically populate field with "Item's MIME type" in HIVE
10.0 Resource Identifier Automatically populate field with "Quick Fetch Link to Item" in HIVE
11.0 Source
12.0 Language Automatically populate field with "Item's Content Language" in HIVE
13.0 Relation
14.0 Coverage
15.0 Rights Management

Further research - link about metadata: http://www.rsp.ac.uk/repos/metadata
Further research - link about metadata schema: http://www.rsp.ac.uk/usage/metadata

Ben: Aligning Metadata Templates to Learning Objects

Worth reviewing: What is IEEE Learning Object Metadata / IMS Learning Resource Metadata?

Have been entering some test documents on HIVE - what I have discovered is that on first impression HIVE populates some basic LOM attribute metadata fields - standard and key data. However, HIVE does allow the entry of data related to all the Root, Branch and Leaf hierarchy of elements in the LOM data model - after uploading.

This facility is useful - as metadata output is an inter-operable standard XML markup for re-purposing in any delivery system.

Future development work:

• Upload more documents and link them in HIVE to show 'aggregation' (related to validation process) - key to searchability/findability of documents and related processes
  
• Match the elements of the LOM / Metadata schemes to the attributes that are required to represent the metadata for the validation documents - may require non-standard fields to be created - specific to the project. his process would require an amended XML file to be imported to HIVE (easily achieved)
  

Ben: Scoping Meta-Data [update]

Have had a brief (informal) meeting with Sam Rowley about XML Meta-Data templates for HIVE. He assured me that many of the templates use some (not all) of the attributes available for that template.

With this in mind - it seems that there is a possibility to match the validation process 'key' data with attribute fields that already exist in specific XML templates. This would allow the validation documents (learning objects) to be marked up for the repository and then be available for 're-purposing' in other systems (IEEE standards for interoperability). In addition, there is an option to 'link' documents through relationship data. This is useful for searching - as it should help complete aggregated searches for all related documents - representing the validation process.

• See wiki entry for IEEE 1484.12.1 – 2002 Standard for Learning Object Metadata
• See IEEE website for a breakdown of this standard
• See Metadata for Learning Resources: An Update on Standards Activity for 2008 (thanks to Fleur Corfield for this resource)

Images - types of meta-data templates in HIVE / Types of attribute fields (example for IMS 1.2.1)

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.

Getting Started!

The DIVAS project has started! The team are all very excited to be involved in such an interesting project that will save staff at the university time and effort in preparing for validation.

I've been working on the following:
* Developing the project plan
* Arranging and atttending the first steering group meeting
* Individual meetings with the team
* Setting up this blog!