Improvements to the SSSOM workflows

[gouttegd]

This PR primarily adds a new value for the maintenance field of SSSOM mapping sets declared in the sssom_mappingset_group: merged.

Given the following configuration:

sssom_mappingset_group:
  products:
    - id: my-set-a
    - id: my-set-b
    - id: my-merged-set
      maintenance: merged
      source_mappings:
        - my-set-a
        - my-set-b

The my-merged-set.sssom.tsv set will be created by merging the my-set-a.sssom.tsv and my-set-b.sssom.tsv sets.

If source_mappings is not set for a merged set, the default behaviour is to use all the other sets as source, so the example above is actually equivalent to:

sssom_mappingset_group:
  products:
    - id: my-set-a
    - id: my-set-b
    - id: my-merged-set
      maintenance: merged

(This is as discussed in #106.)

This PR also brings a few other changes to the SSSOM workflows:

A. Another maintenance value, custom, to explicitly declare that a set is to be built using a custom rule in the custom Makefile (similarly to the module_type: custom for import modules).

B. The possibility to use the xref-extract command of the SSSOM ROBOT plugin, rather than sssom-py parse, to extract mappings from an ontology. This is done with a new group-level option, mapping_extractor. The default value for that option is sssom-py, which preserves the existing behaviour of using sssom-py parse. If set to robot, mappings would be extracted using robot sssom:xref-extract.

C. New helper rules to force mapping sets to be re-serialized, similarly to the normalize_src rule (normalize-sssom-X to re-serialize mapping set X, normalize_mappings to re-serialize all sets).

closes #106

[matentzn]

Looks fantastic. Two optional comments!

[matentzn]

I am assuming you thought this through - I recently struggled hard with a pipeline that provided a merged sssom mapping set which was partially extracted from upstream, but partially generated by the pipeline itself.. So, something like: build a bridge, then extract a mapping set from that, than merge that into a mapping set you publish. This caused some circularity. I don't think this is the case here, just wanted to share my experience.

[gouttegd]

I am not sure I understand your concern, and how it applies here.

In any case, the only change here is that the logic to handle the absence of a source_file key has been moved from within the Makefile template to the odk.py script. This is so the template can simply says

$(MAPPINGDIR)/{{ mapping.id }}.sssom.tsv: {{ mapping.source_file }}

instead of

$(MAPPINGDIR)/{{ mapping.id }}.sssom.tsv: {% if mapping.source_file is not none %}{{ mapping.source_file }}{% else %}$(EDIT_PREPROCESSED){% endif %}

This is functionally identical to what we had before, only with a (slightly) more readable template.

[matentzn]

Maybe to be more future proof this could be sssom-py and sssom-java (in case someone implements a stellar mapping extraction method in robot itself :P). Ok fantasising now, but.. suggestion.

[gouttegd]

in case someone implements a stellar mapping extraction method in robot itself

I think that’s highly unlikely :D but OK, I have no objection with that.