Re-map code for export to ILS to accommodate change from direct link to blank node in local adminmetadata

[NancyL]

When the adminmetadata template was added as a blank node to the instance & work templates, catalogers were very happy (they can now mostly ignore it), but it has caused issues with the local adminmetadata template which is used to entered a Symphony ckey in order to overlay a Symphony record on export. We had been creating a separate local adminmetadata description & linking to it (as we had been with regular adminmetadata), but now that is not possible, since we cannot duplicate a property unless they each go to separate resource templates. So currently record overlay is not possible.

I would like to change the local adminmetadata to a blank node for the following reasons:

1. The current modeling no longer works unless we remove the blank node adminmetadata template from the instance and work templates. This would be very unpopular among users.
2. It would make it the same modeling as the regular adminmetadata template & resolve the issue
3. Having the local template attached to local Stanford templates would increase efficiency on the part of users in data entry & give users a visual cue that a description has been exported

I would also like to change the template being used. Instead of pcc:sinopia:localAdminMetadata it should be stanford:sinopia:localAdminMetadata. Both templates are the same in content; the second has a more logical name.

This issue will also be added to the ILS-Middleware issue list.

Note that this is a blocker to Stanford doing production since we cannot currently export a Sinopia description and overlay a Symphony or FOLIO record.

Should be done in tandem with issue #3464

[NancyL]

After thinking about it some more, a different approach to consider.

Changing to a blank node would keep the modeling in line with the general bf:adminMetadata/bf:AdminMetadata, which makes sense. However, I do see that there is an alternative to moving to the blank node. Instead, we could create a local property for adminmetadata that has the express purpose of sending the description to an outside system (here SIRSI & FOLIO). This makes sense in that it is a completely local function of Sinopia and is not useful to share. A ingest process by someone like SVDE could drop that local property more easily.

From the user point of view, if we complete the move to integrating the export button with the ability to add a ckey from Symphony, then this method might also be cleaner & safer (in that its modeling is not dependent on the property being used for other things as well)