I think this question of object modeling raises many design tradeoffs. Our repository is designed to have parent-child or container-content relationships and allows nested containers. So we have a tree structure, which we think will be useful for applying administrative and access control policies as well as browsing.
I think these folders are useful if you need to deal with buckets of objects at once for administrative purposes. (Just as they are useful on a hard disk.) I have itql queries I can share that show how we retrieve the tree structure if you want that. As for representing digital object structure with whole-part relationships, we haven't needed it much yet but we tried to design for the possibility. It is confusing ground to say the least, especially if you also want to design for reuse of those parts. In my opinion the trade-off comes down to practical concerns about the Fedora data object. If you just want to represent source data that is complex, you might just create a slew of datastreams and one XML or RELS-INT datastream to bring them all together. However, if you start to supplement the source data with additional formats, extracted metadata, surrogates, full text, etc... Then I think objects can become quite unwieldy from a design standpoint. You have to create more places to slot this supplementary data. It gets harder for me, when looking at complex objects that are also enhanced in this way, to separate the different layers out. The cost of atomistic models is that in some cases you have to perform operations that range over the whole bundle, such as validation of a complete structure or some migrations. A very interesting subject and I also hope to hear thoughts from some of the other repositories out there. Does anyone have a good test for this kind of thing? Does it come down to reuse of content models, as in having an image model that can also partake in a cartographic model? The reuse of content models within other models leads pretty easily to the reuse of the parts of digital objects. Greg Jansen Carolina Digital Repository Hilderbrand, Barbara (GSFC-272.0)[LIBRARY ASSOCIATES OF MARYLAND LLC] wrote: > > I’m looking into using the Atomistic Model with my collections. > > I’m trying to find the best way to connect the parent objects to their > child objects. I’ve set up queries similar to those in collection > objects which would work well for the currently collections I’m > working with. However, some of the later collections I’ll be working > with are larger and creating queries for the parent objects just isn’t > feasible. I was wondering if others would be willing to share how they > set up their relationships and Content Model Architecture? > > The collections I’m currently working with are non-archival and > usually only have one to three child objects, so I’m also wondering if > it’s even worth it to use the Atomistic Model or if I would be better > off with the Compound. > > Thanks for your time, > > Barbara > > Barbara Yates Hilderbrand, MLS > Metadata/Digital Collections Librarian, Library Associates > NASA/GSFC Library > Code 272, Building 21 > Greenbelt, MD 20771 > > 301-286-6246 > [email protected] > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-commons-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
