On 15/04/11 15:45, Pat Lockley wrote:
>>> Alright, here's a scenario - I'm a teacher, and I want make me an OER
>>> concerning, say, recording music. Parts of this OER will remain the same for
>>> years on end, such as microphone placement, or compression techniques. But,
>>> the constituent resource concerning multi-track recording has moved on;
>>> where as before we were focused on one bit of kit, or one software package,
>>> or whatever, now we're using the newfangled thought-controlled MindCubase.
>>>
>>> The OER remains the same, one part of it's content has moved on. In this
>>> instance, the idea of an OER as an aggregation is perfectly real, and the
>>> idea of describing it as such surely makes sense. Not a 'red herring'.
>> So make them all independent OERs, and then make one OER that is a link to
>> all of the latest OERs -- and index all of them. Because here's the thing:
>> in your example, even though much of the world will have moved on to
>> MindCubase, a lot of users without the USB 4.0 MindShare dongle/implant will
>> still need that old-fashioned OER about the boring keyboard-controlled
>> Cubase.
>> Individual OERs are potentially valid at the smallest possible granularity,
>> and aggregations are equally valid. Paradata should be able to accumulate
>> around all of them, yes? "I loved the microphone module!" "I hated the
>> compression module." "I loved the whole course and took it from front to
>> back."
>> How will metadata describe the difference between "individual" and
>> "aggregated"? I don't know, but I suspect it's a question we should perhaps
>> defer, and leave up to the creator of the resource to solve. If the
>> resource creator links the individual resources back to a parent resource --
>> "go to next lesson, go to top of lesson" -- then all that matters is that
>> the seeker finds his way anywhere into that chain. If the resource is
>> *interesting*, the user will mostly likely have enough hints to figure the
>> rest out from context.
>> --g
> I don't think that system works though.
>
> So let's say we have the following
>
> Lesson handouts
> Tech guides
> Midi files
> Sound files
> Software files for mysterious system x
>
> So we need to link these OERs together. Now you could use DC:relation,
> but strictly speaking they aren't related. So you should use
> dct:ispartof - but no one does. But some how you need to provide the
> link. Lets assume we just past a URL into the description for now.
> This URL links into OER for mysterious system x.
>
> Now someone wants to upgrade mysterious system x, to it's new version,
> mysterious system x2. So do you revisit all the other OERs to change
> the link. Because if both the parent OERs are valid. Now let's say
> someone comes along and uses spurious system x to make a new OER using
> the same materials. So then do you need three links in each file, or
> do you store each OER as a complete item as well as an aggregation.
>
> Then some one comes along and Oggs the files as that's a more open
> source format.
>
> Then it turns out spurious system x get's a new flanger tool and that
> sounds better so they change their wav (most of the description is the
> same, apart from the word flanger). Then where you land in the chain
> is a bit random.
>
> So you could upload one file with the relations explained. Or upload
> each one separately and rely on associated data being pasted in and
> maintained all the time? The manual multiple uploading and submitting
> sounds like a bit of a maintenance nightmare.
>
> You probably want an SVN or git repository really, something which
> supports forking, but recognises the relationships.
>
I second Pat's suggestion to stick everything in Subversion and have
done with it :)
And if we aren't going to do that, and stay on the Web and all, then
lets do this:
Greg, you're speaking of versioning, great, if that's what you're after
we can do that with OAI-ORE - it supports both the relation
thisAggregation->IsAggregatedBy->thatAggregation.
--
Alex Lydiate
Software& Systems Developer
LTEO - WH5.39
University of Bath
01225 383576
|