Install profile: Object type configuration via System Model and Resource Type fields

[kspurgin]

Paige (Whitman/IMIG co-convener) attended a recent open meeting at which Noah (Born Digital) suggested/recommended the MIG should review the System Model and Resource Type field value combinations and their effects on object views in the install profile.

The MIG discussed this in our 2022-02-14 meeting and agreed that we should make an issue and representatives from MIG should be ready to discuss this issue at the next Tech Call.

We looked at and discussed this draft feedback document in our meeting. It is included here as background/more info only. No one in the MIG meeting made specific disagreements with anything in this document, but it was also not approved as an official MIG statement.

The current Resource Type/System Model term interactions

Object Type	Resource Type term	System Model term
Binary	[any]	Binary
PDF	[any]	Digital Document
Collection	Collection	Collection
Compound Object	Collection	Compound Object
Newspaper (parent of newspaper issues)	Collection	Newspaper
Book (parent of pages)	Collection	Paged Content
Newspaper Issue (parent of newspaper pages)	Collection	Publication Issue
Video	Moving Image	Video
Audio	Sound	Audio
Basic Image (jpg)	Still Image	Image
Large Image (tiff)	Still Image	Image
Newspaper Page	Text	Page
Page (i.e. book page)	Text	Page

This table was taken from a screenshot sent to me (Kristina) by Noah at Born Digital. During the 2022-02-14 IMIG meeting, a link was provided to a similar table in Born Digital's Site Owner Manual which also specifies that an Islandora Display Hint/Islandora Display Term value must also be set in order for objects with viewers (PDFjs or OpenSeaDragon) to render correctly.

Summary of MIG feedback

• Resource Type means a specific thing to people who work with descriptive metadata. It does not mean "some category specific only to how Islandora should display things"¹
  • In any system, a clear distinction should be made between: (1) data/metadata/whatever that exists for and is used by that system internally in specific ways to drive important system behavior; and (2) data/metadata/whatever that is expected to be portable between/reused by systems. Descriptive metadata has always been the latter. The way Resource Type is currently being used here is the former.
  • In any metadata context outside the specifics of Islandora/Drupal data modeling, a given book, newspaper, or newspaper issue is NOT a collection. Recording Resource Type = Collection for these means the Resource Type field should not be displayed or output as descriptive metadata, because it is inaccurate. Essentially, this setup has taken over a commonly used/well understood descriptive metadata field and made it into something else for Islandora's own internal use.
  • The Resource Type terms that come with the install profile are limited to the DCMI Type Vocabulary. LOC's Resource Types vocabulary is also commonly used and does not map neatly/exactly to DCMI or vice versa.
• If an additional field (beyond System Model and possibly Islandora Display Term) is needed to make Islandora display things correctly, a new, system-specific field should be added and clearly named/defined to reflect its role in the system. (Islandora View Type, perhaps?) The Resource Type field should be left alone for use as expected in descriptive metadata².
• However, we also noted that the Resource Type values as currently set up in this logic, don't make logical sense or add any info:
  • NOT USED: Determining Binary or PDF object type is based on System Model term alone
  • REDUNDANT: A number of the Resource Type/System Model term pairs are completely redundant: Collection/Collection, Moving Image/Video, Sound/Audio, Still Image/Image. People responsible for metadata should not be required to enter redundant data for every object in the system, in perpetuity, in order for objects to display correctly
  • NOT SUFFICIENT: Somehow the system knows how to display a Basic Image vs a Large Image despite both having Resource Type = Still Image, System Model = Image. We suspect this requires the assignment of Islandora Display Term = OpenSeadragon, though we were not asked to review (or sent for review) the associated Islandora Display Term value information.
  • NOT SUFFICIENT: Somehow the system knows how to handle a Page (i.e. Book Page) vs a Newspaper Page, despite them having the same Resource Type, System Model, and Islandora Display Term values
• The exception to "the Resource Type values as used do not add any info" may be that Resource Type = Collection is used in combination with System Model values Compound Object, Newspaper, Paged Content, and Publication Issue.
  • HOWEVER, the fact that these system models should, specific to the manner in which Drupal/Islandora models content, be treated as collections is more appropriately encoded as internal system knowledge/behavior, and not offloaded onto metadata creators to re-state every time they create new metadata for these kinds of objects
• We appreciate there may be a future with many possible viewers and use cases where an institution wants to use ThisFancyPDFViewer for one object and ThatOtherPDFViewer for another object, and thus the ability to specify viewer per object makes some sense... HOWEVER:
  • The default viewer to use for a given system model/media type should be configurable elsewhere in the system, and a person entering metadata for objects should not have to specify for every single Digital Document/PDF that the viewer should be PDFjs
  • Similarly to Enhancement: Constrain available Media Use terms to relevant addable media types #1660, the values available to set for Islandora Display Term should make sense given other values. For example if your System Model = Digital Document, then you should not be able to select Islandora Display Term = SomeEmbeddedVideoViewer

In addition:

• As mentioned and bolded a couple of times above, but worth saying on its own: initial developer expediency MUST NOT be at the cost of requiring users of the system to perform error-prone and redundant data entry and maintenance labor in perpetuity
• Call things what they are and use consistent naming/terminology.
  • If System Model = Digital Document is always and only supposed to be a PDF, the System Model value should be PDF. Not all digital documents are PDFs.
  • If Publication Issue is only applicable to Newspaper Issues, call it Newspaper Issue
  • If Paged Content = Book, then call it Book
  • If Page and Newspaper Page are two different things, call them Book Page and Newspaper Page for clarity/consistency. If they are the same thing, don't introduce Newspaper Page as an apparently separate concept.

Footnotes

1. In descriptive metadata, Resource Type (or equivalent fields) is typically used to record an indication of the general manner in which a resource is used by a human. Thus it is appropriate for a TIFF of a book page to be assigned Resource Type = Text because the page will typically be used by being read, even though the representation of the book page is technically an image file.
   A TIFF of a blank book page should not be assigned Resource Type = Text.
   A TIFF of a book page that is wholly a photograph or illustration should be assigned Resource Type = Still Image
   Islandora needs to display all of these as TIFF images, which is a completely different concern than Resource Type ↩

2. This will include re-defining it as a multivalue, non-required field. ↩

[noahwsmith]

Just seeing this now. I'll see what I can do to get feedback here and on Rosie's PR soon...

[rosiel]

I'd like to propose that we use a different (default) set of terms for Resource Type in the Starter Site. Whereas:

• Field Model is a set of islandora-specific terms that drive behavours,
• Field Resource Type is intended to be a more expressive, descriptive metadata field that can be ported between systems,
• There is currently significant overlap between the values in the Model vocabulary and the existing defaults in the Resource Type vocabulary, which makes having two fields less useful.

I think that metadata would be better served by using the Library of Congress' Resource Types Scheme ("resourceTypes") which is a list of 33 values, hierarchically aligned. The list and hierarchy are displayed here (since the id.loc.gov site doesn't have a good display of all of them).

Rationale:

• It's an existing controlled vocabulary appropriate to a "resource type"-esque field.
• This would remove the annoying inconsistency that all the existing values in the resource type vocabulary come from DCMI Types, except Collection which takes its URI from the BIBO scheme because of a conflict with the otehr (pre-existing) "Collection" term in the Models vocabulary.
• It's a short list, which makes it easier to implement (than something like LC Genre/Form Terms which has over 2500 values)
• with the possible exception of "audio musical" and "audio non-musical", they are very friendly and human-readable (especially compared with vocabularies such as the RDA Content Type which includes terms like "two-dimensional moving image". This makes them very good as facets!
• This would create a clear distinction between system-internal values and descriptive metadata
• Use of this vocabulary was proposed in the "Summary of MIG feedback" (above, if i'm reading it right)

I'll make a PR shortly along with a set of instructions for converting an existing set of nodes (if that is desired).