Improvements for linking artifacts via relationships

[lauratinnel]

Is your feature request related to a problem? Please describe.
The set of relationships we have assumes you are adding the relationship on a publication or software artifact-- the system only has the set of forward > relations (cites, extends, supplements, describes, processes, produces, requires). We purposely limited the set to reduce the number of options a user must consider.

When adding the relationship on the right-hand side artifact (e.g., the publication describes software, but adding on the software artifact, the relationship is really "software is described by publication", but the only option is "describes". This is confusing.

Describe the solution you'd like
Change the options in the UI to "describes / described by" (for example), so the user chooses the type of relationship.
Under the covers, derive the correct directions and assign appropriately so the relationships read:

• publication describes software
• software is described by publication

This should work for describes/described by, processes/processed by, and produces/produced by for publication/software, publication/dataset, and software/dataset. cites/cited by, extends/extended by, supplements/supplemented by and requires/required by (for publication/publication and software/software) cannot be inferred, so users will have to get that right.

An additional improvement would be to only show the valid options based on the two types. During the 2021 ACSAC BoF, the Rafael started to select supplements/supplemented by for linking the publication and software artifact. If the source artifact is type publication and the destination artifact is type software, the system could automatically choose describes/described by. if the source is software and the destination is dataset, the system could present only the processes/processed by and produces/produced by relationships.

In thinking about it, maybe the options should be:

• Publication to publication

  • cites
  • cited by
  • extends
  • extended by
  • supplements
  • supplemented by

• Publication to software or dataset

  • describes/described by

• Software to dataset

  • processes/processed by
  • produces/produced by

• Software to software

  • requires
  • required by

We may also want to add the description in the selection text just to help further guide users.

This would do two things: 1) guide users to select our intended relationships to keep the metadata clean and consistent and 2) reduce the cognitive burden on the user in trying to select the right relationship.

Describe alternatives you've considered
Add all the relationship options back, regardless of the artifact types, which will lead to users choosing the wrong relationships and the metadata being polluted.

Additional context
Here's the table of relationships we "desire":
https://searcch.cyberexperimentation.org/best-practices/artifact-relationships

This issue came out of the 2021 ACSAC BoF.

[carboxylman]

An initial blocker is that if the user is trying to use one of the inferred backwards relationships, they cannot do this if they do not own the "source" artifact. So at a high level, this will not work with the current ownership model. Users currently have no choice but to start adding a relationship from the artifact they own to another (which they may or may not own. FWIW, we have already muddied this water by displaying the reverse relationships automatically, even if the owner of the pointed-to artifact didn't approve said relationship. That possibility did not occur to me when the automatic reverse relationships were added; we should refactor that display to clarify (e.g., "other artifacts that link to this one") so that we are consistent with the current permission model.

[carboxylman]

To support this kind of thing explicitly, we would need either the feature where a non-owner can make proposed edits and the owner can approve the edit. Or change the ownership model. Or drop the inferred reverse relationships and make them first-class relationships. Even if that causes cycles, at least we know the users explicitly added them.

I'm honestly not sure which of these to consider the best approach at this point, and it might be wise to pend until the ownership model is resolved.

In the meantime, we can clarify that the relationship being added is a link from the source (where they click "add related") to the dest. The Add Related popup card obscures the rest of the page, so it should be straightforward to add prefatory help text.