Let's de nerd this for the people who sometimes see daylight.
When someone else is editing a word file, word won't let you edit it -
only take a read only copy. You could then try to make changes to
this, but it might affect the person's changes you can't see.
Now google docs allows for multiple editors, but again you're never
quite sure if you're deleting some ones work.
What subversion and git do is allow any number of people to take a
file from a system. Let's say your working on a paper - some one is
doing the data tables, some one is doing the attribution and some one
has come in to neaten up a typo. Now when they all save their changes.
The system will tell them there is a problem, but then endeavour to
resolve those problems (it can work out if conflicts have occurred and
then solve them automatically).
You can also take a set of files and then fork them. Forking means to
make a sister / brother project of the main system. This is usually to
work on a separate feature or to build in some changes which might
affect / alter the main project (such as making it work for different
audio systems).
Subversion and git also support recording changes so mistakes can be
removed, or people can use files without having to update.
Submitting to a repository like this sounds hard - but it can be as
simple as right-click (send to) and thats that. This also gives a user
the benefit of having remote access anywhere storage (cloud, if you
will), and effectively file backup (that's what I use github for
mostly).
Other benefits include seeing who has made what changes to files, so
contributions can be measured and such like.
I think i have convinced myself an OER-github makes an awful lot of sense.
On Fri, Apr 15, 2011 at 4:14 PM, Alex Lydiate <[log in to unmask]> wrote:
> 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
>
|
