Proposal for basic SSSOM governance policies

[matentzn]

The goal of SSSOM is to define a fully community-managed extensible standard for the representation of mappings. It is deliberately not as rigid as ISO or W3C standards, and welcomes proposals from across the community. This is a first basic suggestion for some minimal governance:

Changing / extending the SSSOM data model

• Every edit to model and documentation logic requires an issue
• Edits to docs that do not change the meaning of the spec do not need an issue and can be done in a PR
• Every pull request must be approved by two members of the sssom core team before merging (core team is responsible for merging).

Core team membership

• Membership to the core team is requested on the issue tracker.
• Membership to SSSOM core team is granted at the discretion of the existing team using a form of Disapproval Voting.
• Reasons for disapproval must be made on the core team internal GitHub pages. Before the new member is admitted, the core team may choose to delete the discussion.

Conflict resolution and voting

• Conflicts between SSSOM core team members and modelling alternatives are reconciled through time-bound votes using GitHub (show example).
  • By default, the expiration date of a vote is 1 month after the issue. In urgent cases, this can be reduced to 14 days.
  • Everyone on the core team can issue a vote.
  • Votes are issued as comments on Github issues.
  • The issuer of the vote needs to elicit at least 3 votes in support of a choice.
  • The issuer of the vote is responsible for counting after the vote expiration date. They take a screenshot of the final vote and call the outcome in a comment.
  • Once a vote is called (using a dated screenshot?), further voting will be ignored.
  • Votes against changes that change the current spec count double

Publications / Attribution

• Everyone on the core team is automatically an author on SSSOM standard related papers and can propose other co-authors
• Larger external institutional contributions should be acknowledged on the repository's main README.md

[matentzn]

I am a bit worried if the core team is open that it can literally be hijacked to change existing elements - somehow I would feel better if we changes to the existing spec need to be unanimous..

[mellybelly]

you could have decision making tiers and processes: Primary core team - need unanimous decisions for major changes (which needs to be defined, but could include breaking changes, new elements, etc.) Community - +1s - we could require a certain number of +1s from community and require addressing more than one -1, or somesuch.

[matentzn]

I think that is a good idea:

• Tier 1 changes: breaking changes (changes that could affect existing SSSOM mappings) need to be approved by at least 5 members of the core team, and not opposed by anyone (unanimity)
• Tier 2 changes: major non-breaking changes need to be approved by at least 5 members (1+ core team, rest can be community) and not have more than 4 votes against (i.e adding elements that do not affect other elements)
• Tier 3 changes: minor non-breaking changes only need one approval from the core team (changes to docs, adding examples, etc) and should have more approvals than veto votes.

[matentzn]

Melissa:

• governance will evolve over time
• we can organise changes to governance in a similar way as the standard
• it wont be perfect - better to have something to start from

Versioning:

• we need to organise semantic versioning
• we short inherit some of the versioning protocols from linkml
• we need to decide what is a patch and what are breaking changes

Decide exactly what is in scope for SSSOM and what is not; and document.

• Use case (biomappings) @cthoyt - curated natively in the mapping format natively, not derived stuff (users can directly contribute)
• Alex: computational mappings of terms - genomic know. normalisation effort. Our own mapping algorithm . we want to be more precise and use sssom; we need to get a sense how to apply SSSOM - how to use downstream tools for reconciliation / and how to map our own elemnts
• Davera: hl7 (version in the context of a profile) - the underlying code system may change - this can impact your metadata -> Management problem VPIDs PIDs for sources; we need to coordinate these mappings with

[ahwagner]

👋 thanks for capturing the above. To provide some clarifying details, we want to be better at documenting our computational cross-mapping work. This is easy for our disease normalizer; we just default to MONDO when we map a search term to a MONDO concept. We have to roll our own mappings across different resources for other domain concepts, e.g. genes & therapies.

What we need to know is more about how to use SSSOM to improve transparency about this process and enable better automated traversal of our mappings in search. Also, would like to know more about provenance; indicating when a mapping is manually curated, automated with some degree of certainty, and when it is updated.

[matentzn]

how to use SSSOM to improve transparency about this process and enable better automated traversal of our mappings in search

In its purest form, SSSOM is a format, not a toolbox. The fact that we are developing surrounding tools should be merely incidental - we don't want to create another complex dependency in anyways software stack. There is no quick answer for your question, but I will also have to answer it in much more depth when I start working on OxO 2 - which is basically the answer to your question - we don't have them written down yet. For now, if you provide adequate metadata (see our 5-tier system proposal and aim for tier 4 or 5 :), then the rest is about tools. Thanks a ton for the input @ahwagner !

Also, would like to know more about provenance; indicating when a mapping is manually curated, automated with some degree of certainty, and when it is updated.

Shall we meet up about this? I think its best to show you instead of a lengthy back and forth :) We can use the opportunity to improve our "How to do great mappings" tutorial as well.