856 generation for virtual objects should happen in releaseWF to be consistent with how every other type of object gets released

[andrewjbtw]

Some background

Virtual objects are unusual among SDR objects. They are items that consist of relationships with other items. The structure that results looks like this:

virtual object
    ├── constituent 01
    ├── constituent 02
    └── constituent etc.

The goals of the virtual object model is to make it possible to:

• View and discover the virtual object as a single (aggregate) item
• View and discover each constituent of the virtual object independently as its own item
• When viewing a constituent, see that it is part of a larger item

This means that there are two display requirements for virtual objects:

• For the virtual object: show the object as if it's a single item
• For each constituent: show the constituent as a single item AND show that it is part of a larger item (the virtual object)

The classic virtual object use case is an atlas or book of maps where:

• the book is an item
• each map within the book is a constituent with its own purl

Example: https://searchworks.stanford.edu/view/10448742

This virtual object contains about a dozen maps. When viewing the object in SearchWorks, it looks like a single digitized book.

When viewing a constituent, SearchWorks shows the image for the constituent plus a context widget on the left-hand sidebar that indicates that the item is part of a larger object. This widget links to the virtual object.

Example constituent from: https://searchworks.stanford.edu/view/hp623ch4433

What does this have to do with the 856?

There are two ways a virtual object constituent can get into SW:

1. Via SDR descriptive metadata and the releaseWF (in which case the SW URL ends in a druid)
2. Via the 856 in an ILS record (in which case the SW URL ends in a catkey)

In scenario 1, the 856 doesn't enter into consideration and the releaseWF does everything we need. The vast majority of virtual object constituents fall into this scenario. In this scenario, the SW display uses the relationship metadata in the Public XML to indicate that a constituent is part of a larger virtual object.

From a user standpoint, the way to release a virtual object and its constituents to SW under scenario 1 is straightforward: run the releaseWF on both the virtual object and its constituents. This works whether or not the virtual object has an ILS record: the key in this scenario is that the constituents do not have ILS records.

In scenario 2, SW doesn't read the Public XML, it reads the MARC. So the virtual object relationship for each constituent has to be recorded in the 856 for each constituent. Otherwise, SW will display the constituent items without showing the context widget that links up to the virtual object.

In this scenario, it is unclear how to release the virtual object's constituents to SW so that their relationship to the virtual object gets displayed.

From a user standpoint, it makes the most sense to use the releaseWF for this purpose. However, in my testing, the releaseWF does not create the proper 856 for constituents with catkeys. The 856 being generated just looks like the 856 for any ordinary item, with no mention of the virtual object relationship.

The code for virtual object generation does include a method for generating an 856 for virtual object constituents, as demonstrated in #4413 . From a user standpoint, this is a strange place to put the 856 logic. An 856 is only relevant if an SDR item is released. Yet in testing, it appears that the code to create an 856 is invoked when a virtual object is created, regardless of whether or not the object and its constituents are released.

A proposal

1. Do not create, or attempt to create, an 856 when a virtual object is created.
2. Instead, create the proper 856s when the releaseWF is run - as is the case with every other SDR item.

Additional context

The current code to create an 856 for virtual object constituents while creating the virtual object has two issues:

1. It doesn't currently work. My attempts to create virtual objects consistently failed on stage when the constituents had catkeys.
2. It's vulnerable to being overwritten by the 856 generated during the releaseWF. The most likely process for a user creating a virtual object and releasing it to SW is this:
   • Associate druids with catalog records
   • Accession the images
   • Create virtual object
     • In the current implementation, this will create the 856 (assuming we fix it)
   • Run releaseWF
     • In the current implementation, this will create another 856 and overwrite the previous one. This 856 will not include relationship metadata

Rather than make 856 generation during virtual object creation work, shifting the 856 logic to releaseWF should solve the problem.

[ndushay]

This is a clear explanation of what you desire. Is this what you are suggesting?

Diagram for reference

from: https://docs.google.com/drawings/d/1Nh55tgb3DdJn1WShE4xTjC6OKOQtA9zf6ia0eYcSxzo/edit

1. in the above diagram do NOT create 856 fields for constituent objects with the ConstituentService - the right side of the drawing above
2. in the regular flow for releasing objects to SW (the left side of the drawing above), determine if the object being released is a virtual object. If not, proceed as the code does now. If so, then also add 856 fields with the appropriate information showing they are part of a virtual object.

@andrewjbtw:

• Would you please provide example 856 fields for consituent objects that are badly formed, and for how they should be formed now?
• Would you please provide the algorithm to identify an object being released as a virtual object
• Can we get from the parent object to the constituent children, or are all the links stored in the constituent cocina?

[andrewjbtw]

Responding in order, as best I can with what I know:

in the above diagram do NOT create 856 fields for constituent objects with the ConstituentService - the right side of the drawing above

Yes - isolate 856 to the releaseWF.

in the regular flow for releasing objects to SW (the left side of the drawing above), determine if the object being released is a virtual object. If not, proceed as the code does now. If so, then also add 856 fields with the appropriate information showing they are part of a virtual object.

I think we only need to identify that an item is a constituent and what it is a constituent of. The virtual object release is working (the example I used above has a catkey), it's only when a constituent has a catkey where we're missing something in the 856.

I'm not sure how we identify when something is a constituent now. In the Fedora era that was expressed in the RELS-EXT. There must be code somewhere that identifies constituents because the public XML does include a reference to the virtual object and that must get inserted into the XML ... somehow.

Would you please provide example 856 fields for consituent objects that are badly formed, and for how they should be formed now?

I only have an example of an 856 that's missing some information. For stage druid bc908my0492 the 856 has everything it needs except for a reference "up" to the virtual object it's a part of (which is vt942bb2527).

1441	bc908my0492	.856. 41|uhttps://sul-purl-stage.stanford.edu/bc908my0492|xSDR-PURL|xitem|xfile:bc908my0492%2Fnrs_19170814_0008.jp2|xcollection:st590tq5119::release test|xrights:world

I think the code that's currently in the constituentService may contain the relevant 856 fields. Maybe it's supposed to be a use of x|set? Another approach would be to find out from Access-side code what 856 fields SW makes use of.

Would you please provide the algorithm to identify an object being released as a virtual object

It's not clear to me if the virtual object needs any special handling that isn't already covered. But something in Argo is detecting virtual objects already, and it might be by checking the Cocina for "hasMemberOrders"? The 856 already looks fine for the virtual objects that I've seen, AFAIK.

For the constituents, as noted above, I'm not sure how the determination is being made in DSA. On the Public XML, you can see the relationship in the MODS:

<relatedItem type="host" displayLabel="Appears in">
  <titleInfo>
    <title>virtual object with thumbnail, constitiuents have catkeys</title>
  </titleInfo>
  <location>
    <url>https://sul-purl-stage.stanford.edu/vt942bb2527</url>
  </location>
</relatedItem>

The relationship to the parent is not in the Cocina for the constituent, so there must be a query[?] that's determining virtual object membership.

Can we get from the parent object to the constituent children, or are all the links stored in the constituent cocina?

An odd feature of virtual objects in their current implementation is that:

• In Argo, you can get from the parent to the constituents (in the contents list)
• In sul-embed, you cannot get from the parent to the constituent purls, but you can view all the constituents within the viewer

But for the constituents:

• In Argo, you cannot get from the constituents to the parent
• In Purl/SW you can get from the constituents to the parent

For purposes of the 856, I think it's sufficient to be able to get from the constituent to the parent and not the other way around. So the constituent 856 needs to refer to the parent but the parent 856 doesn't need any special handling.