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 -- _______________________________ Peter C. Gorman Head, University of Wisconsin Digital Collections Center 218 Memorial Library Madison, WI 53706 [email protected] (608) 265-5291 ------------------------------------------------------------------------------ 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
