This is similar to issue MVF-5, where that class was not explicitly defined in the ontology from the outset.

As a convenience for UML modelers or modelers using other profiles, a profile for MVF would allow UML tool users to apply MVF without requiring other changes to tools.

This would require both the profile itself as a machine readable file and documentation for it in the MVF specification. An optional compliance point should be added to cover the new profile.

hasMVFEntry is a property used to relate an element in any model to a corresponding MVF entry. It corresponds to the property ElementEntry in the metamodel. That property has a UML Element in its domain, which cannot be modeled in the ontology, but a note is needed on the property hasMVFEntry to state as much. It should only have one subproperty, corresponding to the property ElementCurrentEntry in the metamodel, however. The property relating a vocabulary entry to an MVF entry should be a separate property, and the narrower/broader properties should not be subproperties of hasMVFEntry.

It should be a PrimitiveType with an xsdType of anyURI

This is an object property that was eliminated from the commons collections ontology, so in order to maintain consistency, it needs to be moved to the MVF ontology.

The terms may be confusing, and implementers may 'misplace' important pieces of information

'uri' is meant to be an 'individual/instance' URI, that identifies the entity represented by the MVF element
(e.g. an individual Community - mapped by a mvf:Community, or an individual Concept - mapped by a mvf:MVFEntry)

'externalReference', which only applies to MVFEntry, may be better called 'semanticReference', and be exepcted to resolve to a definitional resource such as an ontology (class/expression)

'reference' seems to hold more descriptive/informative links such as web pages or other web resources.
Maybe it could be called 'descriptiveReference' - in contrast with 'semanticReference'?

According to the UML diagram in the spec (page 15), there should be a root abstract class "MVFEntry"

This class is missing from the XMI document posted on the OMG website, though the XMI contains (dangling) Generalization references

From a usability standpoint,
at the date this issue is raised, not all UML tools support MVF natively.
In particular, the tools would miss the mvf:ElementEntry and mvf:CurrentElementEntry links from a mof:Element to an mvf:MVFEntry

As a workaround, one could define a UML profile that provides the necessary associations

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

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.