Proposed changes to enable viewing multi-part Collections in a Mirador 3 Window

[sdellis]

(Related to issue #2354.)

Mirador 3 currently assumes a one-to-many relationship between a Manifest and Windows (e.g. a single Manifest may be associated with many Windows). However, the user experience conveyed in the Multi-volume Work (MVW) wireframes reveals that a single Window must also be able to present not only many Manifests, but also data about a Manifest's parent or sibling Collection. This Collection data allows users to navigate from one volume to another and can also allow them to drill into sub-collections that may exist in a multi-part work.

In order to make it possible to view a multi-part Collection within a Window, two significant changes must be made to the Redux store schema based on guidance found in the Redux documentation:

1. We must not assume that IIIF Resources are only Manifests, but could also be Collections which have a hierarchical relationship to other Collections and Manifests.
2. We need to allow for a many-to-many relationship among Windows and IIIF Resources.

Additionally, since item order is important (unless the behavior is specifically unordered), the order of children items must also be available for each Resource. Because of the hierarchical nature of Collections, a simple array of ids given in the documentation example will not suffice. Moreover, since we need to know the items order specifically related to the parent Resource, so one might be inclined to store the parent and sort information with the Resource like so:

{
  iiifResources : { 
    byId : {
      5 : {
        id : 5,
        isCollection : true,
        json : { ... },
        parentId : null, // indicates root Resource with no parent
        sortOrder : 1
      },
      6 : {
        id : 6,
        isCollection : false,
        json : { ... },
        parentId : 5,
        sortOrder : 1
      },
      7 : {
        id : 7,
        isCollection : false,
        json : { ... },
        parentId : 5,
        sortOrder : 2
      },
    } 
  },
  windows : { byId: {}, allIds : [] },
  windowResource : {
    byId : {
      1 : {
        id : 1,
        iiifResourceId : 5,
        windowId : 2
      },
      2 : {
        id : 2,
        iiifResourceId : 6,
        windowId : 2
      },
      3 : {
        id : 3,
        iiifResourceId : 7,
        windowId : 2
      }
    }
  }
}

One wrinkle with this approach is that it is possible for a single Manifest to be a child of different Collections. Should a user want to view two different Collections that contain the same Manifest in two different Windows, using the URI of the manifest as an id and storing information about the parent Collection will not work, since it may have multiple parents. An better solution (that may also have performance benefits) would be to place the parent and sort information in the "join table" to manage the hierarchy and order. Here is the proposed structure:

{
  iiifResources : { 
    byId : {
      5 : {
        id : 5,
        isCollection : true,
        json : { ... },
      },
      6 : {
        id : 6,
        isCollection : false,
        json : { ... },
      },
      7 : {
        id : 7,
        isCollection : false,
        json : { ... },
      }
    } 
  },
  windows : { byId: {}, allIds : [] },
  windowResource : {
    byId : {
      1 : {
        id : 1,
        iiifResourceId : 5,
        windowId : 2,
        resourceParentIdSort : null // indicates root Resource
      },
      2 : {
        id : 2,
        iiifResourceId : 6,
        windowId : 2,
        resourceParentIdSort : { id : 5, sortOrder: 1 }
      },
      3 : {
        id : 3,
        iiifResourceId : 7,
        windowId : 2,
        resourceParentIdSort : { id : 5, sortOrder: 2 }
      }
    }
  }
}

Comments, thoughts, or suggestions?

[sdellis]

I should be more clear about the windows schema. Not a lot changes, but see the below proposed change and question about collectionIndex:

windows: {
	byId : {
  		'2': {
    		// manifestId: '6', // this goes away in favor of `selectedManifestId`
    		selectedManifestId: 6, // default to first Manifest in parent's `items`
    		collectionIndex: 0, // what is this for? I see it in the store, but it doesn't seem to be used anywhere
    		id: '2', 
    		... // all other `windows` properties remain the same
  	},
	allIds: [ 2 ] // if window order is important
}

[mejackreed]

Thanks for putting this together @sdellis. I like the idea of moving from manifest to a generic type. I did have a few questions about this approach.

What is the sort order used for?

Could we just store presentation api resource type?

@aeschylus does this have any implications with your work on ranges and TOC?

[sdellis]

@mejackreed The sort order is optional and can be removed. I stuck that in there in case the order of windows is important to maintain, since that seems to be the best practice based on the docs. If not, then let's remove it as well as the byId property and just keep it simple.

Yes, we can just store the Presentation API resource type. We already have that in the json, but it may be cumbersome to continually look up values in that for application logic. Also, one assumption I have is that we only want users to be able to view multi-part collections in a Window, not all collections. So, if we wanted to specifically store the Resource Type for application logic, we'd likely want to also store the behaviors values too.

[mejackreed]

@sdellis I've had a little bit of time to think about this, and based off of recent changes in Mirador and designs in #2598 I think I've had a change of how I might approach this problem.

Some recent improvements in window state, and Mirador instantiation enable us to specify both manifestId and canvasId in a window. Since a MVW is a special type of collection, it feels more appropriate to instead use collectionId (with of course the associated redux/state needs) as a way to reference a collection that is part of a window.

Similar to how a window can determine the canvasId from a received manifest, the window should also be able to determine the manifestId based off a received collection.

We can continue to keep state living in places where it already is, and I would see this as an additional extension.

Perhaps future work could include instantiation generalization that knew how to broker if an object was a manifest or collection.