[New metadata element]: mapping_set_source

[matentzn]

In order to support mix and match scenarios of mappings, it would be great if we could distinguish mapping_sets that are derived from other mapping sets, and those that are source, e.g. original. I would like to suggest the following three tags to support this use case:

• mapping_set_category: single valued ENUM:
  • original: this mapping set is managed right here, and this is the original
  • mirror: this mapping set is an exact mirror of another mapping set
  • derived: this mapping set is derived in its entirety from a set of other mapping sets (mapping_set_source). The method for that should be indicated in the mapping_set_description. All mapping sets that can be obtained from a server like OxO would be considered derived.
• mapping_set_source: list of entities: the set of mapping sets (ideally versioned purls) from which this mapping set is derived. For example, the mapping set could be a merge and reconciliation of three other mapping sets.

EDIT: see below, we no longer propose to add mapping_set_category until a crispy use case comes along.

[matentzn]

@graybeal what do you think of this suggestion - I expect a lot of copying around of mapping sets, and I really want to document derived, but I am uncertain if the original, or mirror suggestions will fly. Maybe just do mapping_set_source for now which I assume is uncontroversial?

[graybeal]

It's OK but didn't grab me. Partly because the end user use case ("Gee, I have this problem I can solve if only I knew which of these mapping sets is derived") felt a bit weak, partly because the definition for what it means to be derived wasn't precise (what if only some of the mapping are from just a subset of the original mappings), and partly because any name that includes 'category' or 'type' is suspiciously vague (unlike, say, 'mapping_derivation_relationship). I figured it could be added if/when someone came and said "I could really use this."

[matentzn]

Ok, I agree with you. I renamed and rewrote the issue here, which is now fully addressed by #179

[matentzn]

fixed in #179