Merge MappableEntity with DomainEntity

[larrybabb]

The concept of MappableEntity was devised to replace the need for a concept similar to that of the HL7 FHIR data type CodeableConcept. The CodeableConcept type was complex and somewhat confusing and challenging to deal with as we attempted to port it into GKS's schemas. The primary value behind CodeableConcept was the inherent ability to map codings from disparate authorities and/or ontologies to a root concept. As such we discussed and arrived at building the MappableEntity concept which contains a mappings array made up of Mapping concepts. Each Mapping concept in turn, is comprised of a Coding (code, label, system) and a relation based on the SKOs relationship types (e.g. close match, exact match, etc...)

After drafting and piloting the use of the MappableEntity it became clearer to the pilot implementers that this was a much more transparent means of relating codes from other concepts together for the primary concept that the producer of the data wanted to represent. It also provided the same level of flexibility (in the piloter's opinions) as the FHIR CodeableConcept. This benefit rose to the level of moving the implementers to make MappableEntity the parent class to DomainEntity since many if not all domain entities will likely have multiple authorities that provide related codes or identifiers for a similar concept.

It is my proposal here that we simply drop the MappableEntity concept and add the mappings array to DomainEntity as it seems reasonable to this implementer that any MappableEntity could be considered a DomainEntity in the first place. The addition of the extra layer simply complicates the schema and challenges the need to explain why a separate layer is justified for the abstract concept of MappableEntity.

I would like to hear from others if they feel there is a good argument for keeping the MappableEntity as a separate parent class to DomainEntity and why. If you agree with this and you are willing to add your support that would be helpful as well.

Thank you.

[larrybabb]

I believe some folks may think that the utility of having a separate MappableEntity construct is useful since it is congruent to the highly utilized and referenced CodeableConcept (from FHIR). However, CodeableConcept is a kind of ancillary datatype that is convenient for decorating other Resources. In our GKS world we are not taking on a domain that rises to the breadth and scale of 'All of Health Care'. As such CodeableConcept as a separate concept in FHIR is useful for filling in gaps on a broader model that evolves over time with the discovery of elements needed or missing.

I think the DomainEntity can be used as easily as MappableEntity since they are essentially the same exact thing as the schema stands today. So I don't think we lose the ability to use DomainEntitys where we would presumably use something like CodeableConcepts going forward. But as I stated above, it would simplify the schema and avoid us having to explain why the separation of these two classes are justified.

[mbrush]

At first glance I like the notion of simplifying in this way, but need to have a longer think on this. One question that did come to mind immediately was that if we move mappings to DomainEntity, how do we capture identifier mappings for other objects in the data where it might be useful. e.g. specific instances of Documents/Publications?

It seems that you envision Mappings to be more about concept-level mappings (e.g. for things like Genes, Domain entities, Drugs, etc.) - and not for more instance-level mappings (e.g. for things like specific documents/publications, statements, patients, methods, etc. that might have database records/identifiers/accessions in other data systems)? This is apparent from how you describe them, where they are used, and even their definition in the model ("A mapping to a concept in a terminology system.").

Given this, the need for identifier equivalencies for more instance level entities (Document, Publications) could be handled by the identifiers property proposed in PR #18 (which is based on how FHIR does this type of thing). And the Mappings pattern could be used for concept-level equivalencies/mappings there a Coding makes sense to hold the code for mapped concepts. This seems largely consistent with Larry's proposal to push the mappings property into Domain Entity, and my proposal in PR #18 to add an identifiers class to Entity, and with how many other models handle mappings of concepts codes vs equivalency declarations for instance identifiers.

Note that my comments here are relevant to this discussion.

[mbrush]

Update: I went ahead and created PR #20 to illustrate how the changes proposed here might look in practice.

[larrybabb]

After discussion between @mbrush and @larrybabb we decided to move the mappings attribute to the Entity class and drop the MappableEnitty. We will also re-inherit the Document class to the InformationEntity that it was originally based on. And finally, we will repoint the DomainEntity to subclass from the Entity class as well.

The Mapping data type will be a separate datatype like Coding and others and it will NOT inherit from Entity.

[larrybabb]

This issue has been resolved. (see above)