 |
 |
Hi Dan, > > OAI-ORE. I agree with the need to describe aggregations in some form > vs. individual objects and OAI-ORE is worth considering. But I > believe putting an aggregation into an OAI-ORE format should be pretty > straight forward. The bigger question I have relates to what happens > when you have multiple different aggregations. How can you relate the > use of one piece of content in one aggregation to its use in another? > Do we end up with multiple ORE aggregations? Do we try to build an > uber aggregation? Is just storing individual relations in a > repository better than trying to maintain the whole (which might be > harder)? OAI-ORE is all about the aggregation, and doing things like > exchange, deposit, preservation, ... on the whole. > Yep, interesting question. Our proposal is focused, and I think correctly, on solving the problem we've encountered, which is that OER records in the form of those found within repositories such as Jorum are insufficiently described in terms of the constituent resources from which they are comprised - they are in fact an aggregation of resources and so should be described as such, for which purpose OAI-ORE is a good fit. How you'd describe the relations of a single resource to the aggregations of which it is part is a different matter. I wonder, actually, if there would be sufficient use cases for this to be a necessity, and whether to attempt to do so would actually then add complexity where none is needed. Certainly, it is not part of the specific need which we would intend to address. > Beyond the problem being solve, I find the narrative to be focused on > a lot of process and to be very light on the technical deliverables: > "API services to model Open Educational Resources as OAI-ORE > resources and to translate". I'd like to know more. Me too, we've yet to design it, that would be part of the process! We were specifically heavy on the process, and certainly on the process of engaging with an advisory group during the first three months of the project to ensure we create interfaces which could be of the widest use to the community. We'd intend to agree upon those interfaces in the first instance and look to the specifics of the design to best serve them. Alex Lydiate Software& Systems Developer LTEO - WH5.39 University of Bath 01225 383576