Alex, This makes a lot of sense. If there are new images that are edited versions of source images I'd probably create a relationship between the new and source objects, using a predicate like "isVersionOf" or "isDerivedFrom". Or if it's the *aggregation* of the 3 images that's new, and the source images themselves are used as is, I'd create the new object with "hasMember" relations to the 3 source images. That's how we handle e.g. postcards: the front and back views are each a separate object, and there's a logical "postcard" object above them with bilateral hasMember/isMemberOf relationships connecting them. One of our CModels for that logical object is, in fact, CModelCompositeObject.
If you have a logical object that has 3 images that are edited versions of source images, the relationships might look something like this (the bidirectional links are, of course, optional): TopObject -> hasMember -> NewImage1 TopObject -> hasMember -> NewImage2 TopObject -> hasMember -> NewImage3 NewImage1 -> isDerivedFrom -> Image1 NewImage2 -> isDerivedFrom -> Image2 NewImage3 -> isDerivedFrom -> Image3 If you were creating an application that lets someone identify a repository image and grab a copy to edit and save, that application would manage the link form the new to the old object. And the source object wouldn't have to be updated; the new image canjust point back to it. At 11:03 AM +0100 9/10/10, Alex Rodriguez Lopez wrote: >Hi Peter and Patrick, > >Thank you both for this input, I've been actualy truggling with this >collections / aggregations issue too for some time, but as we haven't >started to develop our repo system yet (just at the design phase) I >didn't know how Fedora could manage this (if it could). > >The methodology and conclusions both of you reached will be valuable for >our case! > >But I was wondering, here we have one more use case, regarding >relationships between objects too, let me explain: > >Apart from this 2 types of collections both of you suggested: > >- Permanent/curated collection (system created or externaly aggregated) > >- Ad-hoc/custom collection (user created) > >The user should have the option of creating *new* objects, based on >other objects (being on a collection or not), so they are creating a >*composite* object, not a collection, which would efectively have to be >considered a new object, but still maintain the relation to the used >objects in it. So the user can, for example, grab 3 images from the >local repo or other sources, edit them and add some other stuff >(effectively creating a new object) and save them for their (and >everybody's) use, but retaining this info about the relations (so it is >known that other images are integrated inside). I would call this a >*composite object*, as opposed to that 2 types of *collections of objects*. > >Does this make sense? Has any one in the list had to apply this in a >Fedora repo? > >TIA > >Regards, > >Alex > -- _______________________________ Peter C. Gorman Head, University of Wisconsin Digital Collections Center 218 Memorial Library Madison, WI 53706 [email protected] (608) 265-5291 ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
