Towards #17, are FileSets ever ordered?

[azaroth42]

• [ ] Are the Files within a FileSet ordered? Is there a first and last file?
• [ ] Are FileSets ordered within a Work? Is there a first and last fileset?

Proposal: No and No. If you need ordering, then it's associated with a Work, not with a FileSet. e.g. the Page is ordered, not the set of images and texts that make up the digital surrogate for that page.

[mjgiarlo]

:+1: to the proposal.

[azaroth42]

Journal Supplemental A should be before Journal Supplemental B. Should be presented in the right order.

[azaroth42]

The above comment can be reconciled with the proposal, so long as there are Objects that represent Supp.A and Supp.B. This means (however) that the distinction of what is a Part (and gets turned into a Canvas in IIIF) cannot be from ordered-ness, it needs to be explicit.

[jcoyne]

We've done work at WUSTL, where the object was a book and it had many FileSets each holding an image of a page. They were ordered (the default behavior in curation_concerns). They didn't need to be anything but a FileSet because they had no descriptive metadata.

[escowles]

@jcoyne I think this is the usual case: a FileSet in Plum is also just a holder for an image. Even in Rob's list of more complicated scenarios I think the majority could be accomplished without an extra Page object. For example, multiple digitizations could be handled with two Book objects, each with a FileSet for each page, and the FileSets for the same page could link to each other (dct:replaces?).

[elrayle]

Interesting. I would have expected the proposal to be no and yes.

Options: 1) Book Work (1:1) -> Pages Work (1:m) -> Page Filesets

• Book Work has one subwork Pages Work
• Pages Work has many member Page Filesets, one per page
• Page Filesets are ordered within Pages Work
• IIIF reader implementation can interpret a single work where all filesets in the work are the pages in the book.

2) Book Work (1:m) -> Page Work (1:1) -> Page Fileset

• Book Work has many Page Work subworks, one per page
• Page Works are ordered in the Book Work
• Each Page Work has one member Page Fileset, representing a single page
• IIIF reader implementation can interpret subworks with a single fileset in each work representing the pages in the book.

3) Book Work (1:m) -> Pages Work (1:m) -> Page Work (1:1) -> Page Fileset

• Book Work can have many subworks for varying purposes, but has at least 1 Pages Work to hold pages for the book where no other work exists but the pages
• Pages Work has many Page Work subworks, one per page
• Page Works are ordered in the Pages Work
• Each Page Work has one member Page Fileset, representing a single page
• IIIF reader implementation can interpret subworks with a single fileset in each work representing the pages in the book.

NOTES:

• Option 1: + does not require a significant number of overhead objects purely for organization purposes
• Option 2 & 3: + allows descriptive metadata about each page
• Option 3: + if going the route of 2 or 3, 3 allows the Book Work to have subworks that aren't one of the pages of the book

I have had conversations with more than a few people that make it clear that their expectations are that filesets within a work can have order. That said, if you are building a module that supports the concept of a book with pages viewable via a IIIF reader, then users can be guided through the UI to provide the correct parts and the code under the covers can be implemented in a way to create the model however it is defined. If the module is designed in a way to be plugable into various apps, then the model and data are sharable.

[azaroth42]

We're proposing a different option:

Book Work (1:m) --> Page Work (1:m) --> Page FileSet

In that there are use cases that I believe are in scope for multiple FileSets per Page (per #22)

[anarchivist]

cc @saverkamp (for outside hybox use cases)

[azaroth42]

Given the decision in #22, the question becomes irrelevant, as there's an Object that can be ordered. Filesets and Files do not need ordering.

[elrayle]

@azaroth42 For this use case, or are you saying in all cases Filesets will not need ordering?

[azaroth42]

I personally don't think that FileSets ever need ordering, but that relies on there being a de-conflation of Object and FileSet.

[no-reply]

My take: For this use case.

Use cases where FileSets are ordered within an Object/Work are possible. To date, none have not been identified.

I agree with @azaroth42 that the motivations for ordering that come to mind suggest that what is ordered is the Work, but I wouldn't want to carve in stone that FileSets can never be ordered.

[elrayle]

Perhaps HyBox has a more structured or controlled set of content. Use case, that may be outside of HyBox scope, where ordered FileSets are desired...

• self-deposit IR where users can add as many files to a work for what ever reason. From the user's perspective, the files may have an order. (e.g. I have a work that holds a conference paper, powerpoint presentation, poster, and dataset. I may want to order them in the order listed here.)

[azaroth42]

@elrayle There would be an Object to hold the metadata about the files, including the order.

So self deposit of a journal article, with four ordered supplemental files, would be:

• Work for Article
  • Work for Main Part
  • FileSet(s) for Main Part
  • Work for Supplement A
  • FileSet(s) for Supplement A
  • etc through Supp.D.

And the order expressed according to the Works for the Parts, not the FileSets that group the binary content

[no-reply]

:+1: to Rob's breakdown.

Also, I think we would consider that the "I want to order them in the order listed here" use case is pretty vague.

I totally understand that this is something Institutional Repository users ask for often, but it sounds like an application/display specific concern (i.e. the real use case is "I want the display to put the most important files in the most prominent place"). I think we would want to avoid codifying orders like these in the data model.

[anarchivist]

:+1: to @azaroth42 and @no-reply.

[elrayle]

@azaroth42 Are you planning to create models for each type (e.g. Book, Journal Article, etc.) and have the UI request information about those and under the covers create the Works and Filesets you describe? Because, I agree with your model, but given the conversations I've been in, I don't think there are many self-deposit users who would construct that on their own.

BTW, I am all for defining models with intuitive UIs that don't burden the user with knowledge of the underlying model.

[azaroth42]

By "models" I think you mean in the Rails sense, rather than the RDF sense? If so ... then /I/ am not planning to create them, but I anticipate that such things are needed :) We're only concerned with the RDF/LOD side ... what is the set of resources and relationships that need to be persisted at the back end of the repository.

And yes, the end user should NEVER be required to understand the internal distinctions between RWO, DO, FileSet, Part, File, etc etc etc. :) That would be an epic, epic failure! :)