Barbara,
In my opinion, you are better off with the atomistic approach. Down the
road, it will provide you with the cleanest architecture to manage your
repository.
In a parent-child relationship, the relationship can actually be expressed
as two inverse relationships: A isMemberOf B, and B hasMember A. They
both have the same meaning.
The trick is to be able to define only one of those relationships in the
repository, but be able to resolve or "query" the relationship no matter
which way it is defined. For instance, you want to be able to define A
isMemberOf B on object A, or define B hasMember A on object B, and either
way, be able to find all of the "members" of object B.
We have done this in our repository by defining the relationships in
RELS-EXT datastream. In this way, they can be queried via risearch. Then,
we created a web service that we wrapped around risearch that queries both
relationship definitions. For instance, a request to our web service on
object B for all objects with hasMember relationship will search for all
objects where (<obj> isMemberOf B) or (B hasMember <obj>).
And then we created a service definition and service deployment that uses
the web service to resolve relationships for a particular object.
By convention, we have chosen to only store one of the inverse
relationships in our repository. This is a little easier for us to
manage. In the case of collections, we store "isMemberOfCollection"
relationships on the "member objects". And then we have the ability to
query a "collection" for all of its member objects, or any object to find
what collections it is a member of.
In your case, you might also want to "pick one" and choose a convention
for defining the relationship, either on the child or on the parent. I
suggest defining the relationship on the child object itself, because you
don't want to have to edit the parent object each time you add a new
child.
Dave
-----
David Kennedy
Systems Programmer
Perkins Library, Duke University
(919) 613-6831
[email protected]
"Hilderbrand, Barbara (GSFC-272.0)[LIBRARY ASSOCIATES OF MARYLAND LLC]"
<[email protected]>
04/14/2009 10:43 AM
To
Fedora Users <[email protected]>
cc
Subject
[Fedora-commons-users] Atomistic vs. Compound Model
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
