Both the metamodel and ontology include a class called abbreviation, which is a subclass of vocabulary entry. This seems redundant given that there is a constraint representing the notion of whether or not a given vocabulary entry is in fact an abbreviation.

Having both a vocabulary entry and abbreviation class is redundant

With respect to the ontologies, deprecating this class and replacing it where appropriate with the relevant restrictions will allow for broader usage and eliminate ambiguity.

Note that the resolution to this issue, again with respect to the ontologies, depends on the resolutions approved in Ballot #3 for metadata revisions and content merging.

Currently the specification has definitions for classes, but not for all of the properties used in the metamodel. Some definitions are available in the ontology for these properties, but the metamodel section should be clarified to include them.

Add missing definitions to the document

The missing class definitions are as follows:

• Package
• Status
  And the property definitions:
• MVFEntry::vocabularyEntry
• Community::vocabulary
  In addition the table for Vocabulary misnames "entry" as "vocabularyEntry"

Note that Abbreviation is removed by Issue MVF11-17

Licensing and other details have been updated in the various MVF ontologies, but that has not been done for the informative 'make file' for ease of loading of the ontologies in various knowledge graphs or other tools.

This issue strictly involves updating the metadata in that file, with no change to the specification itself. It depends on the resolution of issues in Ballots #2 and #3.

Update the informative 'load' file for MVF to incorporate latest metadata

The resolution to this issue only involves the 'load file', machine-readable AboutMVF vocabulary, and does not impact the text of the specification.

Diagrams are difficult to create for every axiom change to an ontology, and most ontologists don't use them. However, we have included them in the specification to provide some context and explanatory support, and they should be updated to reflect the changes to the ontologies.

Create new diagrams showing the composite set of changes made to the ontologies

This issue provides the updated diagrams corresponding to the ontology changes made in MVF 1.1. Due to the challenges with older tooling in reproducing the diagrams, we elected to change them once rather than providing new diagrams with each issue resolution. GitHub diffs of the ontologies, available to RTF members and discussed during regular meetings, provided sufficient clarity for members to review the changes.

Currently we've mapped MVFEntry to SKOS Concept, and it should be Vocabulary Entry to SKOS Concept. Likewise, the mapping between MVF Concept System to ConceptSystem should be to Vocabulary in MVF.

In the mapping ontology between SKOS-XL and MVF, the mappings need adjustment

This issue involves changes to the mapping ontology between SKOS-XL and MVF, and does not change any of the other primary ontologies.

It depends on the resolutions to other issues including in Ballot #3 in order to align the mapping with the latest revisions to the ontologies.

This represents a generalization as in UML or OWL, at the metamodel level rather than at the UML model level. This may be confusing to users and so an explanatory note is needed to help. Note that the ramifications of this are at the instance level - one instance of an MVF entry may be a generalization of another instance of an MVF entry.

The same is true of the additional relationship, which is context, where notes and examples would also be helpful.

Expand the notes for broader and context

Add the notes and examples requested.

While the definition of MVF entry and that of SKOS concept appear to be the same, there are differences in how SKOS is used. That may, in fact mean we should consider mapping to MVF Vocabulary Entry instead.

Regardless, it would be useful to provide a discussion in the specification about the possibility, depending on the application.

The mapping from SKOS Concept to MVF Entry may need further review

This issue is essentially the same as MVF11-9, though not identical. Having said this, the suggested resolution is precisely what was done in the resolution of MVF11-9.

The label in the terminology science ontology reads 'term harmonization' and should be 'term formation'.

This issue affects only that ontology, not the documentation for it.

Incorrect label on mvf:TermFormation

The resolution to this issue depends on the resolution of MVF11-21, which revises the metadata on the ISO1087-TerminologyScience ontology.

The change does not impact the specification document, only a very minor change to the ontology, namely to change the label on the class from 'term harmonization' to 'term formation'.

The MVF ontologies depend on LCC for the definition of Language, as do other standards. The joint MVF and Commons RTF teams agree this should be added to the Commons library, and then MVF should be modified to use Commons rather than LCC.

Revise MVF to reuse Commons 1.3 ontologies rather than LCC

This resolution depends on the metadata and other ontology changes described in MVF11-13, MVF11-18, and MVF11-15 (Ballot #2).

Eliminating dependencies on the LCC ontologies, while enabling their use in specific applications, such as to reuse the individual definitions of various languages from ISO 639 and countries from ISO 3166, will simplify the MVF ontologies and make them more reusable.

The changes described in the revised text and attached ontologies are needed to support usability and reuse requirements of various users, including the Retail Domain Task Force and for Identification of Medicinal Products (IDMP-O) developed by the EDM Association and Pistoia Alliance members.

We need a new property to link MVFentry to its VocabularyEntries.
The problem is this bad restriction on MVFentry:
<owl:Restriction>
<owl:onProperty rdf:resource="&mvf;hasVocabularyEntry"/>
<owl:onClass rdf:resource="&mvf;VocabularyEntry"/>
<owl:minQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minQualifiedCardinality>
</owl:Restriction>
However hasVocabularyEntry is specifically for linking with a Vocabulary. If used to link an MVFEntry with its VocabularyEntries then the MVFEntry will get inferred to be a VOcabulary due to the following::
<owl:ObjectProperty rdf:about="&mvf;isInVocabulary">
<rdfs:subPropertyOf rdf:resource="&cmns-col;isMemberOf"/>
<rdfs:label>is in vocabulary</rdfs:label>
<rdfs:range rdf:resource="&mvf;Vocabulary"/>
<owl:inverseOf rdf:resource="&mvf;hasVocabularyEntry"/>
<skos:definition>has containing vocabulary</skos:definition>
</owl:ObjectProperty>

Overly constraining inverse on property isInVocabulary

The resolution to this issue depends on the resolution to MVF11-15, to include all of the metadata changes made in Ballot 2.

The challenging restriction isn't the issue here (and doesn't exist). Currently, there is a link between MVF entry and vocabulary entry - an MVF entry 'is signified by' min 0 vocabulary entry. The inverse is on vocabulary entry, and after MVF11-15, states that a vocabulary entry denotes max 1 MVF entry.

However, to ensure that there are no issues in saying that a given vocabulary entry can occur in things other than vocabularies, we can relax the inverse on the property isInVocabulary.

A numeric ordering is a kind of systematic ordering, with a couple of important attributes: (1) what the origin is – zero or one, typically, and (2) whether it is from low to high or high to low. Typically numeric orderings of collections use positive integers, but there could be other kinds of ordering that use, for example, alphabetical with numerals and/or distinctions by rank, such as A.1.1.

There may also be utility in having the notion of 'position', such as a position in an ordered list, or position of a term in a text.

We have not captured this clearly in the ontology and should.

Need an extension in the terminology science ontology for numeric ordering

This resolution adds two kinds of systematic orderings: (1) numeric order, as requested by the issue, and (2) chronological order, which is also common in collections, concept systems, nomenclatures and the like and was also missing.

It depends on the resolution of MVF11-21 for metadata changes to the ontology.

While typically one would associate a vocabulary entry with only one MVF entry, this does not allow for cases when a vocabulary includes more entries than are mapped to MVF entries. Thus, one could have terms that either are not needed or have yet to be mapped, and the restriction would result in wrong results (or a rule that exercises the restriction could do so).

The restriction in the MVF ontology should be modified to 'max 1' from exactly 1, and the redundant restriction in the ISO 1087 ontology that says 'min 0' should be eliminated.

The constraint on vocabulary entry stating that it denotes exactly 1 MVF entry is incorrect

This issue was largely addressed by the resolution to MVF11-18, on which it depends and on MVF11-13 with respect to metadata.

However, it removes a redundant constraint on the class 'vocabulary entry' that was mistakenly added in the ISO 1087 Terms and Definitions ontology.

There may be cases that vocabularies may not have a relationship with an MVF entry. The constraint should be loosened to be [0..1].

The constraint in vocabulary entry that it denotes exactly one MVF entry is too narrow

The resolution to this issue depends on the resolution to MVF11-13, which addresses revisions to the metadata for the ontology.

The resolution simply revises the cardinality on VocabularyEntry, on the property denotes, to change the cardinality from exactly 1 to max 1.

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.

Just prior to publication of the FTF report, a new property was added to the metamodel called descriptiveReference. This property, which is quite useful, was not added to the ontology, however, and may eliminate the need for restrictions using the Commons is defined by (cmns-dsg;isDefinedBy) property on VocabularyEntry.

The MVF ontology does not reflect the addition of a descriptive reference property

The resolution to this issue adds the equivalent data property for a descriptive reference to the MVF ontology, together with a restriction on MVF element to match the metamodel.

It depends on the resolutions approved in Ballot #2 for metadata purposes.

There is an example in Annex B that is quite useful, but is not multilingual. Since we have said that MVF can be used to support multiple natural languages, we need at least one additional example to cover that use case. We might also include a broader example showing how to represent a general vocabulary in MVF, such as the AI PTF emerging vocabulary for artificial intelligence, to show how this can be done.

More examples are needed to demonstrate how to use MVF

While the RTF agrees that we need more examples, and, in fact, we've been working to add a new annex with some work done by Stephen Powley through his Ph.D. thesis at Coventry, we believe more time is needed to add that annex and integrate any additional changes needed to support his findings.

We also plan to add examples specifically related to use of the ontologies, based on the work underway between EDMA and the Pistoia Alliance on the Identification of Medicinal Products (IDMP-O) ontology. Again, doing so will take additional time, and some of the changes incorporated in the 1.1 revisions are needed for IDMP-O in order to support those examples and other use cases in early 2026. Having the revisions be included and dereferenceable is critical for IDMP-O.

The property 'currentMVFEntry' on the association ElementCurrentEntry changes the multiplicity from 0..* to 0..1, so it should be redefines not subsets (or the parent multiplicity needs to be changed)

Property 'currentMVFEntry' changes the multiplicity, so it should be redefines not subsets

The intent of ElementCurrentEntry is to select from several linked MVF entries., and allow that selection to change between them. hence it does not override the full set but selects one from them, of which it needs to be a (single-member) subset. So the model is correct in this regard.

This might be a new area of exploration, and could apply beyond MVF entries in the context of MVF.

Currently the metamodel reflects SKOS-like relations such as broader and narrower, but more is needed for certain applications.

It would be useful to have a non-normative annex demonstrating how one could do this as a starting point for MVF users.

Additional mapping capabilities between MVF entries would be useful

The 1.1 RTF has been working with Stephen Powley through his Ph.D. thesis at Coventry, to investigate extending the metamodel and ontology to incorporate more nuanced mapping properties as well as examples to support those extensions.

This work is still underway, however, and we believe requires more effort, including additional testing and documentation, prior to inclusion in MVF. We think it is important however, and that it could provide significant value to the broader community, and so we plan to focus more on this for the MVF 1.2 RTF.

The purpose is to reflect the equivalent of package ownership in a source model: the name should better reflect that.

Metamodel property "MVFEntry::context" is unclearly named

The idea behind this is that a given MVF entry may point to another MVF entry that provides context, but it needs more research and some testing. As a consequence, the RTF elected to defer this for MVF 1.1.

Investigate whether this should be on vocabulary, vocabulary entry, both, and/or possibly on a more general element as well.

There may also be an impact on the ontology, depending on the resolution.

Consider adding more contextual properties to vocabulary entry

This issue is more of an enhancement and is a bit vague. We need some examples / use cases to tease out what might be valuable to add in this case. Thus, the RTF decided to defer to MVF 1.2.

MVF users have requested that the form of the XMI that is provided as a part of the MVF specification be canonical XMI.

The published XMI should be generated as Canonical XMI

Canonical XMI generation is currently mainly manual, and some scripting work or other development is needed in order to make this more consistent, not only for MVF but more generally.

We are deferring this due to limited resources to create the requisite artifacts and document them in an annex at this time, given that it is lower priority than some of the other revisions needed for MVF users.