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.

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.

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.

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)

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

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.

Added profile with MVEntry and MVFEnabledElement stereotypes

The proposed UML profile includes two stereotypes

MFEntry applies to any Element. Adds a 'semanticReference' anyUri that can be used to link the UML element to an external semantic descriptor. Useful for those models that need the MVF 'concepts' but not the MVF 'terms'

MVFEnabledElement also applies to any Element. Adds an 'mvfEntry' reference which can be used to associate an (instance of) MVFEntry, which in turn can be linked to the other MVF entities

See the attached document, MVF Profiles.odt, for the revised text of this resolution. The new clause should be included in the document immediately following the clause specifying the metamodel.

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'?

Rename properties as proposed

Rename MVFEntry::externalReference to semanticReference
Rename MVFElement::reference to descriptiveReference

Update the metamodel and ontology diagrams and document text referencing these names, as given below in Revised Text.