On Wed, Sep 21, 2011 at 6:02 PM, Edwin Shin <[email protected]>wrote:
> Just to clarify, when you say "compound objects" you're not referring to a
> complex single-object model (i.e. single object with many datastreams) but
> actually to a multi-object model (many object linked via RELS-EXT), right?
>
> It's usually the former that is referred to as complex and the latter as
> atomistic, see:
> https://wiki.duraspace.org/display/FEDORA35/Content+Model+Architecture
>
> FWIW, I usually prefer asserting part/membership relations in the child
> rather than parent object. If you have the Resource Index available, it's
> straightforward to query the relevant relationships for export.
>
It is a multi object model. For an example of one kind of compound object
I've been looking at, we have collections of sheet music. A single volume
often contains multiple songs, and each song frequently contains multiple
pages. There are other objects with multiple levels of hierarchy
Asserting relationships in the child would not be a problem. Because I'd be
asserting the relationship after the parent and child are loaded (i.e. the
children all of RELS-EXT associated with them) for data that I'm migrating,
I'm trying to figure out if I'd be likely to introduce problems because of
any other relationships those children might have. However, I can see that
pointing from the children to the parent would be less problematic for items
being added one at a time after the automated migration is complete.
kyle
--
----------------------------------------------------------
Kyle Banerjee
Digital Services Program Manager
Orbis Cascade Alliance
[email protected] / 503.877.9773
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
