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
