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 Em 09-09-2010 21:06, Peter C. Gorman escreveu: > Patrick, > > You have summarized precisely the discussions we've had here about > collections and other aggregations, you've have reached the same > conclusions we have, and for the same reasons. Our "Curated > Collections" are aggregated via isMemberOfCollection relationships in > member objects' RELS-EXTs, But "Custom Collections" (though I also > like your term "sets") explicitly list their members in the > collection's RELS-EXT only. We also did not want objects to be > updated ever time a user adds them to an ad-hoc aggregation; it seems > better to keep those relationships focused in one place. I'm not sure > you need to point back from the object to the ad-hoc collection - > querying the RI for "collections that claim me as a member" should be > sufficient. > > We haven't discussed here the access policy issue you describe, but I > don't think you necessarily need a different relationship type to > separate the 'real' collection memberships form the ad-hoc ones: you > could assume that any collection relationships you need to query the > RI for also need to be tested for access policies. > > At 2:49 PM -0400 9/9/10, Yott, Patrick wrote: > Content-type: multipart/alternative; > boundary="Boundary_(ID_ckfY6Cl5zSxDZNsq4UJJ5w)" > Content-language: en > > I'm working on some design issues for our about-to-be implemented > digital repository and have been tossing around some ideas about how > to handle collection objects. My uncertainty arises when I try to > draw a meaningful distinction between a "permanent" collection and a > "user-created" aggregation. > > Let me explain. > > Suppose we create a collection of art images that can be used by any > member of our faculty for instructional purposes. Clearly we would > create a collection object and would use the "isMemberOf" or > "isMemberOfCollection" verb in the RELS-EXT of any object that is > deposited into this collection. Seems clear enough and easy to > manage. > > Now suppose two faculty members each wish to use this image in their > classes. Our plan to allow them to create "ad-hoc" collections based > on any material in the repository to which they have access and then > to allow them to interact with this collection in BlackBoard or any > other instructional tool they wish to use. My uncertainties arise > when thinking about how to encode this type of relationship. At this > point I don't like the idea of adding a RELS-EXT to the object each > time it is "subscribed" to a class-based collection object. Instead, > I think it makes sense to have these collection objects be explicit > in listing their members, most likely via a "hasMember" verb in their > RELS-EXT data. > > I suppose I could assign specific semantic value to "isMemberOf" that > would allow an object to refer to these ad-hoc aggregations (perhaps > better to call them sets?) and let "isMemberOfCollection" always > refer to a relationship to the collection into which this object was > originally deposited, but I'm not overly keen to use hair-splitting > to solve this problem. > > My reason for this is that we can expect a range of permissions on > these instructional collection objects and any given image object may > be related to collection objects with differing XACML policies. As > we intend to offer a "see this object in relation to others" service, > I don't want to include collection nodes in a graph if the user > doesn't have permission to interact with these collections. > Obviously this premise extends beyond simple class-based collection > objects but to any aggregations a user may wish to maintain. > > So, I'm wondering how others have approached this issue, and if my > thinking makes any sense (at all). > > Thanks for your input and advice! > > p > > Patrick M. Yott > Digital Library Manager > Northeastern University Libraries > 360 Huntington Avenue, SL270 > Boston, MA 02120 > p 617.373.4194 > f 617.373.5409 > <>[email protected] > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > > _______________________________________________ > Fedora-commons-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > ------------------------------------------------------------------------------ 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
