MVF11 — The restriction on MVF Element stating that it can only have one textual name is overly constrained

MVF element is the parent class of both MVF entry and vocabulary entry. A given term, which is a vocabulary entry may be used in various ways, and in some cases may have multiple textual names. This isn't common, but does happen in practice, especially in cases involving legacy data.

One case we have found on the IDMP-O project is that there are two sources for the same term. The European Medicines Agency publishes controlled vocabularies are specified in the EMA SPOR reference ontology (RMS). That ontology includes not only EMA SPOR controlled vocabularies but duplicates a subset of the controlled vocabularies from MEDdra (Medical Dictionary For Regulatory Activities). In the IDMP representation of various pharmaceutical products, both controlled vocabularies are required for use in the EU. Thus we have the EMA SPOR version of the MEDdra term and the actual MEDdra term, which we map to one another using owl:sameAs. That results in a logical inconsistency because we have more than one term name for the same term. We have similar issues with certain FDA controlled vocabularies, where they have identifiers specified in the GSRS and UNII repositories, that are actually the same identifier, thus resulting in two textual names for the same thing.

There may be a requirement for some implementations to use a SHACL shape for this, but for information content, such as the specifications for certain substance names, simply relaxing the restriction from exactly one to some values from would provide the semantics we need.

Loosen constraints on MVF Element to allow for mapping across vocabularies for duplicated terms

There are a number of cases where the terms used for representation and identification of substances, drugs, and other manufactured items are repeated across controlled vocabularies. In some cases they use the same identifier and IRI though not always.

When such terms are clearly duplicates, an ideal mapping would use owl:sameAs. However, MVFElement only allows for one IRI, name and description and thus such mappings, even for identical terms, make the resulting graph logically inconsistent.

Note too that the property, hasTextualName, has been added to Commons and that property should be reused by MVF, deprecating the existing duplicate.