>> 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.