Related (internal) object

[MDiMeo]

We would like an additional field called Related Works. Ideally, this would be off to the side or set apart from the metadata in some way and include thumbnails of the Related Works. A use case is here, where we want to relate two objects that would not be part of a Collection and which are not related by metadata: https://hydra.chemheritage.org/concern/generic_works/br86b356q Until then, we'll continue using Related URL for these and will batch convert them later (if we can.)

[MDiMeo]

We haven't discussed this since April. Post-soft-launch, it would be good to revisit the different ways in which people are using Related URL both in terms of data quality and page redesign to see if Related Works would still solve our problems.

[jrochkind]

Yep both more use case specificity, and (only after that) review of how we might want it to display in public interface would be good before proceeding.

(How it needs to display in public interface can effect constraints on implementation within sufia/fedora. Like, if it needs to be on search results, or just individual item show page. If it needs to be in facets in any way. etc.)

[archivistsarah]

Here are a bunch of potential uses. I don't feel strongly about all of them, but here they are for discussion's sake:

Painting: https://digital.sciencehistory.org/works/br86b356q Photograph of the painting in situ: https://digital.sciencehistory.org/works/s7526c460

Letter: https://digital.sciencehistory.org/works/qv33rx23v Response: https://digital.sciencehistory.org/works/n870zr22b (we have a few chains of correspondence that might be tricky to represent on the front end -- would each letter be related to the one preceding it and its response?)

Photograph: https://digital.sciencehistory.org/works/8910jt96j Composite image using photograph as background layer: https://digital.sciencehistory.org/works/tm70mv622

Instruction manual draft: https://digital.sciencehistory.org/works/k06988039 Final published version: https://digital.sciencehistory.org/works/kd17ct39j

Photograph: https://digital.sciencehistory.org/works/sj139220v Publication including the photograph: https://digital.sciencehistory.org/works/9019s324t

[catlu]

Thanks @archivistsarah for rounding up a bunch of those examples. Here are some more--

https://digital.sciencehistory.org/works/p5547r97z https://digital.sciencehistory.org/works/m039k5624 These two paintings are part of a pair and meant to be viewed side by side.

Spectrograph: https://digital.sciencehistory.org/works/br86b4223 Glass plates made from the spectrograph above: https://digital.sciencehistory.org/works/1j92g7979

DDT can: https://digital.sciencehistory.org/works/6q182k84r Ad for DDT can: https://digital.sciencehistory.org/works/mp48sc895

Also the use case for things with multiple volumes, though those can be pretty easily discovered by keyword search or facets.

[catlu]

In terms of display, my thoughts are that it's not necessary in search results or facets, etc. I was envisioning it on an individual show page only, with a thumbnail and title maybe in a section labeled "Related works" so it won't get confused with the multi-file thumbs.

[catlu]

Use cases look good to me, @jrochkind.

[catlu]

@jrochkind, to answer your Q's from Slack:

• A) Is it okay if they have no relationship “label”, the user just knows it’s a “related object”, not any particular nature of relationship.

Yes, for sure. The expectations for this relationship is sort of a "see also" suggestion feature (except curated).

• B) Is it okay if y’all editors need to symmetrically edit object A to have a relationship to B, and also separately go into B and edit to have a relationship to A? Or is this gonna be too annoying or error prone?

It's not ideal, but editors would be okay with this if it's a lot more work otherwise. Basically, it wouldn't be too big of a deal needing to edit both objects A & B going forward, but it would just be more work when dealing with the back cataloging. But the back cataloging is a low priority for now.

[archivistsarah]

re: using parent-child relationship for chains of correspondence, this would work but I can think of 2 things we should keep an eye on:

1. We'd need some good guidelines for curators on how those are grouped together (this is true for using any kind of relation for correspondence though). Some of the correspondence is between multiple people around the same issue/topic/event -- should those be under one parent work? What about correspondence between two people that stretches over 30 years and is about several different subjects? Correspondence that includes photographs or other items that are separate works?

2. Parent works and child works show up in search results, which might be confusing to a user if they get "Glenn Joseph letters to AOB" (parent) and "Glenn Joseph letter to Beckman, 1955-05-28; Glenn Joseph letter to Beckman, 1955-09-21," etc (children). The "part of" field might have made this less confusing though -- just wanted to toss this out there since I think the correspondence use case will have a less clear distinction for front-end users than parent-child works that have very different names like "Foreign rare book title" and "Plate 1".

[jrochkind]

Thanks Sarah. I think point 1 is going to be confusing no matter how this is implemented. If not as a parent work, how would you imagine defining all those relationships?

If you'd like us to consider it in designing the feature, can you come up with an example, and how the relationships might ideally be displayed to the user?

[jrochkind]

Here's a draft demo of using a parent work for a chain of correspondence. We can play with it and see how we think it looks in the UI, including search results?

https://staging.digital.sciencehistory.org/works/ms35t954h

https://staging.digital.sciencehistory.org/works/1544bp15t

https://staging.digital.sciencehistory.org/catalog?q=prentiss+beckman Note:

1. This will disappear at the end of April when the now regular staging refresh happens. :)

2. It was actually kind of a pain for me to create this! I had to give up on doing it in the actual management UI, and go to the console to do it (where I still had to get past some roadblocks). It's possible our slated work to improve parent/child editing UXs for editors might be able to make this easier.

[archivistsarah]

I definitely don't have a better suggestion. Just saying that correspondence (& archives in general) is tricky, and if we do this, @catlu is going to have to write some really solid guidelines and I/the curators can happily adhere to them. Or we'll just have to document our case-by-case decisions really well.

The draft demo looks good but man, I wish there was an easy way to make the dates visible.

[jrochkind]

make the dates visible where? You mean for children on the parent page?

We could do that... for every single parent page. I'm not sure we want it on every single parent page. But if we did we could.

I think perhaps issues with wanting certain parent pages to have special display formatting -- different parent pages formatted differently from each other -- might be something for a future "exhibitions" feature..

[archivistsarah]

Yeah, I should have specified -- it would be incredibly helpful for this and only this situation.

That said, correspondence is the use case for "related works" that I feel the least strongly about. So if it's causing too many problems I'm not going to fight real hard to keep it.

[jrochkind]

The only use case examples we have so far that involve more than TWO items related to each other are correspondence, and multiple volumes. @catlu I think also doesn't consider the multi-volumes a priority.

So maybe we'll just focus our solutions on the cases we have where we have two items, which should be related to each other -- which comprise most of the use case examples we have so far.

The simplest solutions I can think of for the "two items" situation are not going to work for the multi-item set use cases without being a nightmare, is why I'm distinguishing.

[jrochkind]

One example of three items that were all marked as related to each other already in production data, from @mhpmiller https://staging.digital.sciencehistory.org/works/rv042t46z

[HKativa]

Update: at the DCC meeting on 6/28/2018, we discussed limitations of the related items feature as it was implemented:

• Feature is one-directional and does not cross-populate when one work is linked to another.
• Catalogers can only edit records shared with them (typically items they select for digitization), which limits the ability to create relationships across collecting areas. (It's worth noting that we don't want to change the functionality of user roles/permissions, but recognize that these settings have implications for how the related items feature works).

In light of this discussion, what are our options, if any, for updating this feature to allow "Related URLs" to cross-populate? Also a point of consideration: if implemented, how would this affect records where we've already manually cross-populated by copy and pasting the related URLs into each individual work?

[jrochkind]

We were aware of exactly these limitations when implementing the feature -- I made sure to point them out, and myself was worried that the feature as we ended up implemented would not be sufficient for exactly these reasons.

At that point Michelle and Cat made the decision that the feature as currently implemented was good enough -- that the feature as we have implemented would add significant value, and the additional cost of developing a more complicated feature would not likely add enough additional value to justify. This was based on listing actual use cases we knew about then, and evaluating how the limited feature as we ended up implementing would handle them.

See for instance

• https://github.com/sciencehistory/chf-sufia/issues/338#issuecomment-382456694 (there was more discussion in slack not captured here)

Context, or priorities, may have changed since then though, as a result of changed environment, different decision-makers, learning about new use cases, or experience with the feature as it is. It is okay to change our mind.

It is not immediately obvious what the options are for developing a more expansive feature. We'd have to spend some time "designing" it (the under-the-hood code architecture, as well as what it would look like to staff users entering data, and to end-users viewing data). it would involve beginning with listing out use cases, as we did before. If this has become something prioritized above other possible work to spend time on, we can spend that time. We can't really say in advance what the options are before spending the time.

[jrochkind]

Before, when we realized the limitations with having access to one work but not another -- that is, with being able to edit X to add a relationship to Y, but that relationship would not show up on Y without an additional step, and if you didn't have permissions to edit Y, you had no way to make the relationship show up on Y -- Michelle and Cat thought this might not actually be a "bug" but a "feature", it was unclear if curators without permission to edit Y ought to be able to make things show up on the page for Y.

However, it's possible that is more clear now after use? It definitely is a policy/permissions issue, in addition to a technical implementation issue.

[jrochkind]

The original use cases that motivated this feature were about things that were related by really being about the same physical object or work. See above examples in discussion with @catlu and @MDiMeo : manuscript draft and published edition; spectograph, glass plates made with that spectograph; photograph of object, manual for that object; etc.

It looks like we've now expanded to using it for things related more by "aboutness".

eg https://digital.sciencehistory.org/works/dj52w474d has a photo of chemistry students "related" to other photos of chemistry students, that I don't believe share anything in common other than that.

I wonder if there is a better tool for that then 'related works' -- when I hear 'aboutness', I think 'subject headings'.

But there may be new use cases that are not met by existing tools/metadata. If we are expanding into new use cases, I'd suggest we be do some work to list them out and be clear about what they are, and then we can think about the best technical solutions to provide for them, whether using 'related works' or not.

The details of the existing feature was developed in response to particular use cases and work flows. In particular, it is particularly unsuitable for large sets of works all related to each other, it was really designed for one-to-one relationships. We knew that, as above, and decided to focus on that simpler use case for the initial feature.