Thanks again for the info and explanation! Peter C. Gorman, 10-09-2010 14:32: > 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 >> >
------------------------------------------------------------------------------ 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
