 |
 |
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'. What if the constituent parts are used in different aggregations? Is this of real interest, and to who, and why? If it is, then a mechanism is required to describe it, and we're onto the formal metadata debate, but we're not proving OAI-ORE of no value. If it is not, then there's your red herring. On 15/04/11 13:23, Brandon Muramatsu wrote: > > So your metadata issue is - who is going to use it? Because if no > one is going to use it, then it doesn't matter what format it is in. > > Ok, I've been trying to figure out the best way to insert this into > the conversations. I was going to do it in terms of aggregations. > > I think this is ultimately the point. > > Remind me, why are we discussing taking content and expressing it as > an aggregation? Or creating aggregations of content/aggregations? (I > kinda lost the point in the thread, and maybe introduced the problem.) > > I think it might be to describe individual parts separately, and > express those individual parts via OAI-ORE. > > And then what happens if individual parts are used as parts of > multiple aggregations. And why is that important to an end user, the > author, the repository manager? > > Here I look at OAI-ORE as an expression or container, and perhaps the > red herring. > > It seems to me that what's really of interest is describing the > constituent parts better. But who benefits and why? > > > Brandon > > On Fri, Apr 15, 2011 at 8:17 AM, Patrick Lockley > <[log in to unmask] <mailto:[log in to unmask]>> > wrote: > > > > The Openlearn feeds include relevant resources using an > enclosure tag > > - and in the Xpert database, that content is stored. Now if we could > > get into those PDFs and find pictures, we could provide those > resources > > in the results too. Then a more formal method of understanding the > > relationship between content becomes really handy. > > > Jorum does a similar thing with a lot of pieces broken into parts, > > but then sadly no dc:relation or indication of associated pieces. > > > So there is lots of scope for providing more granular > information on > > learning objects - and this would be great for a "remixing service". > > > > > Absolutely right - a formal and common resource descriptor is, in my > > opinion also, very much a necessity for that kind of granular > > information - our proposal suggesting LOM for this task, DC being a > > good > > alternative. However, that seems to be a point of contention here, > > with > > some people not liking the idea of using formal, standardised > > ontologies. > > Well at the moment there is a bit of a metadata impasse in that > certain systems now want differing forms of data, whereas others > want compliance with X,Y,Z. Some people want a little, some people > a lot. I conducted some experiments on metadata last year > involving bribing people with cake in exchange for metadata. Even > offering people free cake still led to poor metadata. > > So your metadata issue is - who is going to use it? Because if no > one is going to use it, then it doesn't matter what format it is in. > > Now you could possibly repurpose a block of related content into a > single common cartridge package - that would support a packaged > format (vaguely akin to a LOM or DC item) with some metadata, but > also usable in a lot of tools. It's not as remixable as raw > content, but as an exchange format - then it probably has > potential for wider use than providing LOM or DC by themselves. > > Pat > > -- Alex Lydiate Software& Systems Developer LTEO - WH5.39 University of Bath 01225 383576