Clarify difference between `mapping_source` and `mapping_set_source`

[cthoyt]

The documentation for https://mapping-commons.github.io/sssom/dev/mapping_source/ says it takes an EntityReference and gives MONDO_MAPPINGS:mondo_exactmatch_ncit.sssom.tsv as an example

The mapping set this mapping was originally defined in. mapping_source is used for example when merging multiple mapping sets or deriving one mapping set from another.

Is this supposed to correspond to the mapping_set_id of the mapping set where it came from? This seems to be what the example implies. What should be done here when the mapping_set_id can't be easily compressed into a CURIE?

How does this match up to https://mapping-commons.github.io/sssom/dev/mapping_set_source/? This element is defined as a NonRelativeURI and can have multiple values. Its definition is

A mapping set or set of mapping set that was used to derive the mapping set.

This doesn't make sense to me - why are these fields named differently, why do they have different semantics (CURIE vs URI) and why is the first single valued but the second is multi-valued?

Further, should these slots have a propagatable relationship? Like if all mappings have the same source, shouldn't it get collapsed into a metadata-level element? This might not make sense because I do not understand the nuance between these two fields.

[gouttegd]

Is this supposed to correspond to the mapping_set_id of the mapping set where it came from?

That’s my understanding, yes.

What should be done here when the mapping_set_id can't be easily compressed into a CURIE?

Given that the mapping_set_id should be a URI (a “NonRelativeURI“, more precisely), it should always be compressible into a CURIE. What cases are you thinking about where the URI cannot be “easily” compressed?

This doesn't make sense to me - why are these fields named differently, why do they have different semantics (CURIE vs URI) and why is the first single valued but the second is multi-valued?

mapping_source applies to a Mapping (what we now call a “mapping record”). It is single-valued because a given record can originate from only one set (“the mapping set this mapping was originally defined in”).

mapping_source_set applies to a set. It is multi-valued because the records that make up the set may very well come from several sets (if the set is the result of some kind of merge operation).

As for the CURIE vs URI typing: Pretty sure that mapping_source was made a EntityReference (i.e. a CURIE) because it is found in the TSV section of a SSSOM/TSV mapping set (since it is a property of a mapping record), and typically in the TSV section most people want to deal with CURIEs rather than with URIs. mapping_set_source on the other hand is found in the YAML section (since it is a property of the set), where the use of URIs is not considered cumbersome.

Further, should these slots have a propagatable relationship?

They do not really mean the same thing, so no.

[matentzn]

Agree with @gouttegd: same intent, different scope (record vs set), different cardinality follows from that, CURIE vs URI typing follows from the TSV vs YAML convention; no propagation in this case.

@cthoyt agree with "easy compression" issue - the producer has to make sure the source set's URI has a usable prefix in curie_map. From your perspective (semantic farm) this is slightly undesirable because you would ideally like to avoid non standard (custom) prefixes in curie maps.. Its annoying but unfortunately not really anything we can easily fix w/o adding a breaking change to the model now before the 1.1 release.

At the very least we should document the relationship between the two slots. I am not entirely (just weakly) opposed to retyping mapping_source to NonRelativeURI btw. The discussion is a little different here as license and mapping_set_id are MUCH more central to the model, and changing these would have caused real churn. These ones.. I would say, less so.

[gouttegd]

At the very least we should document the relationship between the two slots. I am not entirely (just weakly) opposed to retyping mapping_source to NonRelativeURI btw.

Well, I am.

First because such a change would invalidate all the existing sets that are currently using CURIEs in their mapping_source columns (as they should). This is not something I would consider without a compelling reason.

Second because you would fix a (perceived) inconsistency (between mapping_source and mapping_set_source) by introducing another. All mapping-level *_source slots (subject_source, object_source, and mapping_source) are typed as EntityReference, for the same reason as explained above: they are properties of a mapping record, which means they are found in the TSV section of a SSSOM/TSV file, and we prefer CURIEs whenever possible in the TSV section.

If you re-type mapping_source, then we’ll have subject_source and object_source as EntityReference (i.e. CURIEs) and mapping_source as URI. How is that better? At least the (perceived) inconsistency between mapping_source and mapping_set_source has a logical reason behind it.