Add curie_map to the model

[gouttegd]

Resolves #225

• docs/ have been added/updated if necessary
• make test has been run locally
• tests have been added/updated (not applicable – nothing new to test, the CURIE map has existed for a while, this PR just formalises it directly into the model)
• CHANGELOG.md has been updated.

If you are proposing a change to the SSSOM metadata model, you must

• provide a full, working and valid example in examples/ (no need for a new example – all existing examples already have a curie_map)
• provide a link to the related GitHub issue in the see_also field of the linkml model
• provide a link to a valid example in the see_also field of the linkml model (no need, see above)
• run SSSOM-Py test suite against the updated model

This PR makes the curie_map a bona fide slot of the MappingSet class, that exists independently of the serialisation format.

It builds on top of #349 by explaining in the text version of the spec what the curie_map slot is for, and how it should be dealt with in the SSSOM/TSV serialisation.

[matentzn]

I added the "example" after all, just for completeness reasons. One small comment, then we can merge.

[matentzn]

Awesome thank you!!!

[matentzn]

Looks great, thank you!

[hrshdhgd]

Sorry to repeat this in every PR

run make all same as #386 (review)

[gouttegd]

Sorry to repeat this in every PR

No need to be sorry. :) However:

1. Re-generating and committing all derived files upon every PR is, I believe, a very bad idea.

• It makes even the slightest PR much larger than it needs to be, and therefore more cumbersome to review.
• It pollutes the history of the project with large changes that do not mean anything (only the changes to the source schema are actually meaningful).
• It greatly increases the likelihood of merge conflicts when there are several PRs in the works.

It would be much better in my opinion to leave the auto-generated files untouched most of the times, and only commit them once in a while (typically shortly before a release).

2. If you insist on having the derived files re-generated upon every PR, then it‘s something that should be mentioned in the CONTRIBUTING.md file, which for now has no trace at all of such of requirement – instead it’s full of useless, generic guidelines that were mindlessly copied over from another project.

And since there is a PR template, that requirement should also be mentioned in it.

[gouttegd]

I‘ll fix the conflict here once #375 will have been (re-)approved ­– no point in fixing it now since merging #375 will (again) cause a conflict in the changelog.

[matentzn]

Looks great, thank you!