Note inclusion of deprecated relator terms in default Linked Agent field config in metadata documentation

[kspurgin]

When we remove parenthetical info from display labels in Islandora/islandora_defaults#50 we remove any obvious indication that some of the relationship type terms provided by default are deprecated terms.

Add mention of this to the metadata documentation and note the terms, so individuals may do what they will with this info: ignore it, delete deprecated terms, keep them but add indication of deprecation back to display, or whatever.

Perhaps explain that the deprecated terms are included to support migration of legacy data that may use the old terms.

These are the deprecated terms:

'relators:clb': 'Collaborator (clb; deprecated, use Contributor)'
'relators:grt': 'Graphic technician (grt; deprecated, use Artist)'
'relators:voc': 'Vocalist (voc; deprecated, use Singer)'

[kspurgin]

@rosiel - do you have feelings about whether this is a good idea or not, or suggestions/opinions on the best way to do it?

[rosiel]

No idea. This seems like something that a report could display, as the only reason we want it is as a "todo" flag to the site admin / metadata person. I'm 100% for not displaying it to the public. With the key|label format, we don't have anywhere in the field to put this information... which means that when we strip it out, there's nothing telling a person who sees "Vocalist" in the dropdown that they shouldn't use it. But we must have "Vocalist" in the dropdown because legacy data.

This is maybe wildly inappropriate brainstorming, could we strip out the stuff (in parentheses) before displaying the Label to the user? That way we have key (for the machines), label (for the metadata person) and label (for the public) - which is what we're trying to accomplish here. That will add its own problems, yes. A person might want to use this field with values where they do want to display some parenthetical information to the public. I wonder about using less common punctuation like [] or {} for the stuff that we want the metadata people to see. Or, honestly, sounds like what we need is not key|label but key|label|publicLabel.

[seth-shaw-unlv]

Well, the main reason we left deprecated values in there is to allow sites to import their legacy data and still be able to display sane labels for those values. That said, ideally a site with these old relators would fix these values and then remove them from the field config so they don't add more entries with that relator.

So, do we make it easy to bring in legacy data with the risk that new users will presume it is okay to use the depreciated values (because they aren't familiar with the official relators list), or do we make it safer for sites creating new records by omitting deprecated values at the expense of old data coming in that won't display with appropriate labels? Or do we make the FieldType and corresponding Widget and Formatter more complex to satisfy both?

[kspurgin]

Ok, so I may be missing something huge about all this, so bear with me.

Is there reason that relators (which is a vocabulary) has to be managed as a list in a field definition, rather than as a vocabulary?

Because if relators were a Taxonomy vocabulary this seems like maybe there's an elegant way around this and several other issues.

Here's how I was initially thinking of this, anyway:

• There could be a boolean field defined in the vocabulary term indicating active/deprecated term status.
• You could create an Active Relators view of the Relators vocabulary
• The Agent field definition could be set to use the Active Relators as the Reference method for populating the rel_type property, so people creating new metadata manually wouldn't be able to assign deprecated ones
• You could set the migration to lookup against any terms/codes in the taxonomy vocabulary.

But since the view is defined on the field (and not on the form interface for populating the field), would that work or would those migrated values be rejected as invalid or something?

Anyway, there seem to be a lot of benefits to managing a vocabulary as a vocabulary:

• metadata folks can manage the vocabulary and easily add terms
• linked data predicate can be taken from first field_authority_link value or if there is none, the term URI
• a field could be added to this particular taxonomy vocabulary to indicate relationship type group (creator, contributor, publisher/manufacturer/distributor/etc., other, etc. --- these are groups to which the LC relator vocabulary assigns all the terms so the LC terms could get auto-assigned to the appropriate group from the LC data when the terms get migrated in).
  • this would make it easy if a particular institution wanted editor to be considered a creator instead of a contributor, for the metadata manager to fix that.
  • seems like this would also make it easier to have OAI-PMH, citations, etc generated without hardcoding logic about who counts as a creator vs contributor vs publisher in various places

There are more benefits, but they aren't as immediate to this particular conversation.

I just don't know if the view-is-part-of-field-definition would make this impossible, or if there is a way around that, like enforcing the view in the form display config instead or something...

[kspurgin]

Side thought:

These external vocabularies we rely upon change. There's already stuff like @rtilla1 raised here: https://islandora.slack.com/archives/CM9CVQWJ0/p1618102646022300

Looking long-term, it's unreasonable and backward to expect individual institutions to manually track and manage these changes.

Systems that leverage external vocabularies and deal in linked data will need some kind of mechanism for automated (or semi-automated, with human metadata expert approval) external vocabulary update. That seems a lot easier to eventually build as a tool in Islandora if vocabularies are vocabularies and not key-value pairs in field definitions.

[seth-shaw-unlv]

Is there reason that relators (which is a vocabulary) has to be managed as a list in a field definition, rather than as a vocabulary?

Nope. No reason at all. To make the change would just require someone to modify the field type, widget, and formatter and create an update hook (which, honestly, might be the hardest part). It might be easier to create a parallel field type/widget/formatter so existing sites can migrate themselves if they want.

[kspurgin]

Ask MIG/metadata slack channel which of the following options we prefer:

• Note the deprecated terms in the field documentation that shows in the form.
• Add the (deprecated) back to the deprecated terms (at least this is human-meaningful)

[kspurgin]

MIG went with the second option given above.

Will be fixed by Islandora/islandora_defaults#52