Dor::Item access to de-referenced constituents?

[jkeck]

It would be really useful to be able to have access to a de-referenced object from the isConstituentOf RELS-EXT relationship. It wasn't immediately obvious if this was available via Dor::Item or elsewhere already.

The ItemRelease workflow currently has some code to do this as a stop-gap, but it seems like this is something that would live in dor-services land (unless I'm way off-base).

[jmartin-sul]

i did a bit of searching dor-services code, and it doesn't look like there's a method there to get that, but it does seem like the sort of thing that'd be reasonable to add since other dor-services consumers (and dor-services itself) would probably want it at some point.

possibly naive questions about the highlighted code: is the referenced object always expected to be there (i.e. should the find call be in a rescue, or is a 404 actually fatal)? and is the referenced object always expected to be an Item (or would Dor.find be a reasonable alternative)? just asking because it reminded me of something that was recently partially fixed in dor-services for collection relatedItem elements, but it might've only looked similar.

[LynnMcRae]

@jmartin-sul this is indeed the same thing as dereferencing an APO for a title (expressed in am isGovernedBy relationship) or a collection (expressed as an isMemberOfCollection relationship). This is merely am isConsituentOf relationship. We need common code that takes a predicate relationship to another object ('cause we're likely going to have more after these 3) and returns a title.

[jkeck]

@jmartin-sul I'm assuming that we don't put invalid druids in isConstintuentOf relationships (which is the only execution path for this code).

If that is not true, then I guess we'll find out relatively quickly in our indexing process. :)

[LynnMcRae]

@jkeck we don't deliberately put in bad collection or APO references either, but occasionally a reference could go stale because an object goes away, or any transcription error if there is human intervention. This should be very rare in prod, but it affected the test environments if you were porting objects over for testing.

[ndushay]

Is this addressed by #204 ?

[LynnMcRae]

This is a backlog writeup of a better way to do this I think, with common code at the DOR level shared among APO, Collection and Constituent.