Paul:
|
|Ground rules: Bill Olivier suggested that in the mapping exercise, we
|work as far as possible within the existing elements of the IMS-LIP
|specifications, and avoid using extensions unless there is no other way
|of mapping and that we work within the IMS definitions of the core data
|structures (eg QCL Affiliation).
|
|Section 1 - Multiple UIDs:
|
|I would agree with Rosemary that the idea of a globally unique identifier
|is unrealistic given our current position and that any structure we suggest
|should be able to cope with multiple models of identification.
Agreed
|However I am
|less sure of Adam's suggestion of using the <affiliation><affiliationID> to
|carry this information where it belongs to a single organization.
Could you elaborate?
|
|We can use the fact that demographics is an element which can be used
|multiple times and use it to create multiple UIDs for a single learner as
|in the example below:
|
|<identification>...
| <demographics>
| <comment>Institutional reference number</comment>
| <contentype> <referential>
| <comment>Institutional reference number</comment>
| <contentype> <referential>
| <indexid>UID_Inst</indexid>
| </referential> </contentype>
| <uid>960001111</uid>
| </demographics>
| <demographics>
| <comment>HESA reference number</comment>
| <contentype> <referential>
| <indexid>UID_HESA</indexid>
| </referential> </contentype>
| <uid>111111</uid>
| </demographics>
|...</identification>
This seems OK.
|
|This would handle a simple case of more than one UID for the same
|individual, and would still allow us to use <affiliationID> where we were
|dealing with some form of external registration (eg General Medical
|Council, English Nursing Board). This structure would keep the UID values
|within the identification section of the LIP, where most systems would
|expect to find them. Additionally it is in keeping with the model proposed
|by the ISR-LIP mapping project in FE and is therefore more likely to fit
|with what the commercial partners like BlackBoard and Fretwell Downing
|are doing.
What are they doing?
|
|Section 2 - Involvement of more than one institution:
|
|I agree with Adam here that his "favorite structure" <affiliation> seems
|the best place to hold this information. This would enable us to cope with
|situations such as the one described by Adam with Liv Hope and Liv Uni. The
|awarding institution would appear in the <qcl> structure with the
|institution delivering the tuition being in the <affiliation> field and the
|<classification> being "member":
|
|<qcl>...
| <title>BA(Hons) Human Geography with Physical Geography</title>
| <level>2:1</level>
| <organization>...
| <name>Liverpool University</name>
| </organization>
|...</qcl>
|<affiliation>
| <classification>Member</classification>
| <affiliationID>960000111</affiliationID>
| <typename>
| <tysource sourcetype="imsdefault"/>
| <tyvalue>Student</tyvalue>
| </typename>
| <comment>Student studies at Liverpool Hope University</comment>
| <organization>...
| <name>Liverpool Hope University</name>
| </organization>
| <description>LHU provides the tuition and student support for the
| degree awarded by LU
| </description>
|...</affiliation>
Yes this seems good.
|Section 3&5: <qcl> -or- <activity>
|
|The discussion at Stoke seemed to be more along the lines of what Rosemary
|was saying about the use of <qcl> and <activity> so that we would get a
|structure like:
|
|<qcl> </qcl> # overarching qualification (see section 2)
|<activity> # equating to full programme of
|study
| <activity> # equating to year 1
| <activity> </activity> # module 1
| <activity> </activity> # module 2
| <activity> </activity> # module 3
| <activity> </activity> # module 4
| </activity>
| <activity> # equating to year 2
| <activity> </activity> # module 1
| <activity> </activity> # module 2
| <activity> </activity> # module 3
| <activity> </activity> # module 4
| </activity>
| <activity> # equating to year 3
| <activity> </activity> # module 1
| <activity> </activity> # module 2
| <activity> </activity> # component of module 2
| <activity> </activity> # component of module 2
| <activity> </activity> # module 3
| <activity> </activity> # module 4
| </activity>
|</activity>
I guess this can be thought of like: the "QCL" is the 'bit of paper' and the activities are
the things that you do to get the bit of paper. I conceed that a year of study does
not map to QCL's - I guess it is actually an activity that is itself a collection of activities.
[I dont actually have the latest LIP spec - there seems to more stuff in the activity category
now. I'll try to update myself ASAP.]
I still be happier if the stucture could be
<qcl>
<activity> # Prog o study
<activity> # yr 1 # u
<activity> # module 1 </activity>
<activity> # module 2 </activity>
...
</activity
</activity>
</qcl>
IE, have the activities as 'part of' the qualification. I think the only reason that I'm saying
this is because this is what we do in LUSID. We recognise that virtually EVERY qualification has
some sort of associated activity that must be performed in order for the qualification to be
accredited - the way we represent 'part of' is by nesting. However, the QCL data structure
cannot contain an activity, so unless we use a <qcl><extension><activity> structure, this
cannot be achieved. I guess that
<qcl></qcl>
<activity> ....
<activity> ....
...
followed by a <relationship> element will have to do. It is still very
understandable and the relationship leaves the reader in no doubt about
the, er, relationship between the two structures. Maybe we could ask
IMS if they ever considered allowing an activity to be 'part of' a
qualification, and if they did consider it, why did they reject it??
|
|This allows us to nest the years of study and their component modules in a
|logical structure which as well as coping with the data, also manages to be
|quite human-readable. Once this becomes the holder for the PDP as well as
|the transcript, there can be another nested layer of <activity> which
|relates to work carried out in attaining a module pass (see year 3, module
|2 above). The use of the outermost layer of <activity> corresponding to the
|degree programme allows us to store information about overall credits/marks
|received (see Adam's Section 5 query).
|
|In relation to Adam's other point from Section 5, that was down to my
|misunderstanding as to the nature of the <level> element of <qcl>. I had
|thought that it related to the level of the qualification in the UK
|Qualification Structure (i.e. HE3 corresponds to a BA(Hons) degree). We
|decided in Stoke that Adam's proposal was, of course, the correct way to
|do it:
|
|<qcl>...
| <level>
| <text>2</text>
| <level>
| <text>1</text>
| </level>
| </level>
|...</qcl>
Yes - I was just reiterating for those not at the meeting.
|
|Section 7: Explanatory text etc.
|
|I would agree with both of you that this is not a part of the transcript as
|we tend to think of it, but it does have to be stored somewhere. This is
|part of a larger concern I have over the relationship between transcripts
|PDPs and Degree Programme Specifications. To use an example, I took an MSc
|in IT and Learning with Lancaster University, from which I graduated in
|1999. In 2000 the degree programme structure changed but the qualification
|remained the same. So if we are to know what someone has done in their
|degree we will need to have a transcript, linked to a PDP, linked to an
|archive copy of their degree programme specification, linked to and archive
|copy of their subject benchmark, linked to a description of the structure
|of UK qualifications. Now I will concede that this is overkill for most
|people, but anything else does not tell the whole story...
|
|OK so that is my rant over with for the day. Please let me know your
|thoughts as I will be modifying the consultation document for Peter to
|discuss further with Bill Olivier next week.
Section 7 is very interesting - Paul and Rosemary are right in that all course
related data must now be archived (for ever)!
At 02:50 PM 7/20/01 +0100, Paul wrote:
|>Paul,
|>Your latest suggestions seem fine to me - I hadn't spotted that
|><demographic> could be repeated.
|
|Nor did I the first time I tried this, but the IMS documentation isn't
|meant to be human readable is it ? ;)
|
|>So the record of achievement would all be <activity> not <qcl> ? i.e. the
|>outermost <activity><result> would be the final mark/grade for the course,
|>and within that the same structure would be used for
|>years/modules/assessments within modules, as required?
|
|That is the idea I am working with at the moment - QCL does not have any
|elements which can be used as a holder for final marks, overall credits,
|max possible mark, etc all of which might be useful or required. So I was
|intending to suggest the use of <qcl> to hold the formal qualification (eg
|BA(Hons) Modern Literature [2:1]) and then use the outermost <activity>
|structure to hold what wont fit in the <qcl>.
|
|The advantage of this method (IMHO) is that we are not using any extension
|fields where we don't absolutely have to, as recommended by Bill Olivier,
|and the whole thing actually seems to be quite readable, since it resembles
|the structure of the printed transcript quite closely.
|
|>Keeping data on old degree structures is messy, I suppose it has to go
|>somewhere under <affiliation>.
|
|I agree with you that it is quite a messy process, but when this idea rolls
|out to be the basis of the PDP the Learning Outcomes, Objectives, and
|Skills from the Degree Programme Specification (DPS) will become the
|triggers for action planning in the PDP and so will have to be kept
|somewhere if the PDP is to make sense.
|
I'm still a bit concerned about
Overview of NQF
Overview of UK HE system
I would expect these to be IDENTICAL for each and every transcript produced
in the same academic year regardless of institution. I would also hope that
the text would be supplied by the appropriate administrative bodies.
Ideally I would like 'a pointer' from the transcript into the [archived if
necc.] records of the appropriate administrative so that everybody gets the
same text. Could we not use the content packaging spec to 'include' this
externally stored information? This would also mean that if a 'mistake'
was discovered in the description - it could be corrected centrally and
ALL UK electronic transcripts would be immediately updated! Perhaps I'm being
a bit over the top here but I guess I'm being a bit of a computer scientist
here in not wanting two (or more) copies of the same information being stored
in two separate places.
Any comments on my Accredited skills thoughts?
Adam
--
Dr AC Marshall ([log in to unmask])
LUSID System Programmer, CCAP, University of Liverpool.
Cheese of the Year: Old Amsterdam
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
|
