Updates to how we represent Mappings for Domain Entities in common-source.yaml

[mbrush]

The PR implements changes based on Larry's proposal for refactoring how we represent concept mappings in Discussion # 14

Changes are made to three classes:

• Mappable entity:

  • deleted (we will push its only property (mappings) into Domain entity)

• Mapping:

  • Renamed to ConceptMapping - makes it clear that these being used for concept mappings and not instance identifier equivalencies)
  • Remove its inheritance from Entity. These are more like utility classes / complex data types - they don’t need any of the properties defined on entity (id, label, description, extensions)
  • Minor update to the textual description of this class.

• DomainEntity

  • add the mappings property (as formerly defined on MappableEntity) to this class - added clarifying text to the definition

Note that if there are other concept-like things we end up defining in our model that we end up wanting to capture "mappings" for - we can add this mapping property yo them as well. But at present, and in foreseeable future, this will exclusively be DomainEntities.

Again, capturing other identifiers for more instance-like things in our data (Publications, Documents) will be handled by something like the identifiers property proposed in PR #18. This approach to distinguishing / capturing concept mappings vs instance identifier equivalencies is similar to how many other models work, including FHIR.

IMPORTANT: If we do make the Mapping -> ConceptMapping name change, update this in downstream dependencies.

[mbrush]

On recent modeling call, Larry expressed concern that ‘id’ vs ‘identifiers’ still confuses developers/users – despite increasingly widespread use of this distinction in community models like FHIR.

For now, we decided to move ahead with not defining an Entity.identifiers property, and instead broaden the scope of the Mappings object to accommodate instance identifier equivalency declarations, and concept level code/term mappings.

Changes Larry made here to accommodate this include:

• removed MappableEntity
• move mapping into Entity (assumes it is ok for anything to have a mapping . . . if others not ok with this, we can make a Mappable Entity mixin that any class that needs mappings can inherit from)
• make Mapping a utility class (by removing its inheritance from Entity)

---

This PR was already merged by the time I worte this - and I noted a couple fixes needed:

• change ConceptMapping back to Mapping (since the proposal here is that Mappings will cover instance-level identifier equivalency declarations)
• update descriptions of Mapping class and mapping property to fit their broadened use

[mbrush]

In thinking about how the revised model would be used to capture an instance identifier equivalency (e.g. from a primary pmid for a publication to a pmcid or doi) - issues arise as the Mapping class and its properties are explicitly defined to support concept level terminology/code mappings, not instance level identifier/accession mappings.

• Do we want to still cram all into Mapping (need to rename form ConceptMapping)?
• What about the 'coding' field'? As defined, not useable for instance id / accession number equivalency declarations?
• I don’t have great solution.
  • Do we allow codings to hold database identifiers/accessions?
  • Do we add a separate/new property to Mapping to capture for these dientifier equivalencies?
  • Do we go back to the idea of an Entity.identifers property . . . or maybe use an xref property to capture equivalent identifiers, if this is less confusing?