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>

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

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

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.

An organization ontology that covers formal organizations, legal entities, and organization membership is essential for the ongoing retail ontology effort, for development of an ontology for the emerging PPMN standard, and others.

Note that representation of domicile requires the concept of a geopolitical entity, which the task force agrees belongs in a more general locations ontology. Thus, a locations ontology is also needed as part of a resolution for this issue.

Add new locations and organizations ontologies to the Commons library

The resolution to this issue affects both the specification document and machine readable files. It adds one property to the designators ontology and incorporates two additional ontologies, one describing locations, which is needed for several processes: the Retail Industry Ontology, the RoSO ontology for robotics, a planned revision to the Multiple Vocabulary Facility (MVF), and a planned update to LCC, as well as external efforts, and an organizations ontology, also needed for the RIO ontology and external work.

Requirements range from retail to finance and health care, where certain constructs, such as identifiers, are registered with specific authorities, and understanding who has registered a particular identifier is essential to the definition of that identifier.

Coverage should include definitions for registration authority, registrar (which could be a person or organization, and may or may not be part of the same organization as the authority), a registered identifier, which should be modeled as a contextual identifier, the registry and some registration scheme.

Note that the resolution to this issue depends on Commons-1.2-8, including properties in the organizations ontology.

Add a new ontology covering registration authorities to the Commons library

Requirements range from retail to finance, government, pharmaceuticals, and health care, where certain constructs, such as identifiers, are registered with specific authorities, and understanding who has registered a particular identifier is essential to the definition of that identifier.

The OMG's FIGI standard, for example, allows for a single registration authority (RA), which is Bloomberg LP, but enables multiple registrars to act on behalf of the RA. Today registrars include Bloomberg LP as well as Kaiko.

Coverage should include definitions for registration authority, registrar (which could be a person or organization, and may or may not be part of the same organization as the authority), a registered identifier, which should be modeled as a contextual identifier, the registry and some registration scheme.

Note that the resolution to this issue depends on the resolutions in Ballot #3, Commons-1.2-8, including properties in the organizations ontology.

One example of this is hasNumericValue. It is currently declared to be functional, but could be the parent property for several properties of some class. In this case, the resulting ontology could be logically inconsistent if the values are not the same (and even if they are, by coincidence, that's still a problem). Other properties that are also declared as functional should be reviewed for the same issue.

Revised the quantities and units ontology to remove unnecessary constraints

1. Revised the quantities and units ontology to remove functional declarations on a number of properties. These constraints caused reasoning errors when any of the properties, such as hasNumericValue, were used as the superproperty of more than one subproperty on the same class (concept).
2. Eliminated circular restrictions on system of quantities, system of units and added links back to the appropriate system from the quantity or unit
3. Revised the license to include the copyrights and full text, added Airbus, Ontogenesis Solutions

This would assist in alignment with SysML v2, but more importantly allows alignment of some quantity value with a more general measurement reference rather than only a measurement unit, for representation of IU in pharma, for example.

Add measurement reference to the quantities and units ontology

The resolution to this issue involves:
1. Adding a new measurement reference class, which is a subclass of the union of measurement procedure, measurement unit, and reference material, though not equivalent because there may be other related concepts
2. Adding / replacing the superclass for measurement procedure, measurement unit, and reference material with measurement reference as appropriate,
3. Adding measurement reference as the parent for measurement scale, corresponding with SysML v2, and
4. Adding a new property, has measurement reference, and making has measurement unit a subproperty of has measurement reference

Note that the metadata required for this revision has been applied to the resolution for Commons12-5 and thus the resolution to this issue depends on the resolution to Commons12-5.

These include tax authorities for retail applications, banking regulators in finance, other regulators for manufacturing and engineering applications. A small ontology that supports the definition of regulatory authorities, including their jurisdiction, would be quite useful for these kinds of applications and is needed for the emerging retail industry ontology.

Augment the Commons library with an ontology for regulatory agencies to support retail, manufacturing, and other applications

The primary use cases for regulatory agencies in retail are for tax authorities, but for retail pharmaceuticals, there is also a requirement to be able to represent medicines regulatory agencies and related governmental stakeholder, for example. A small ontology that supports the definition of regulatory authorities, including their jurisdiction, would be quite useful for these kinds of applications and is needed for the emerging retail industry ontology.

Note that the resolution to this issue depends on the resolutions in Ballot #3, Commons-1.2-8, including properties in the organizations ontology.

Definitions of certain kinds of structured collections, including sets, lists, and some ordered collections are not well defined in OWL. A small ontology that includes definitions for these elements is needed for retail and other OMG work in progress.

Augment the Commons library with a small ontology for structured collections

Definitions of certain kinds of structured collections, including sets, lists, and some ordered collections are not well defined in OWL. Examples of ordered collections include chronologically ordered collections and indexed collections. A small ontology that includes definitions for these elements is needed for retail and other OMG work in progress.

Note that the resolution to this issue depends on the resolutions in Ballot #3, Commons-1.2-8, including properties in the organizations ontology.

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.

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.

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.

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.

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.

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.

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.

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.

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

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 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.

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

Augment the MVF ontology to include a class for MVF Element

The resolution to this issue impacts several parts of the ontology, requiring certain constraints to be loosened or eliminated due to adding restrictions on string-valued properties to MVF Element. The solution also addresses a logical inconsistency in the terms and definitions ontology for ISO 1087 that was identified during testing.

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.

Eliminate the property, isRelatedTo, which contributes no semantics

The original Multiple Vocabulary Facility used a property from the beta version of the Commons Ontology Library, 'isRelatedTo', as a means of structuring other properties. It was removed from Commons and based on FTF discussion, should be removed altogether from MVF as well.

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.

Limit the usage of hasMVFEntry to correspond to its usage in the metamodel

The resolution to this issue unwinds some circularity in restrictions and clarifies the meaning of hasMVFEntry to better reflect the metamodel.

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.

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

The UML Profile for MVF issue is a duplicate of MVF-4

This issue should be closed to the resolution of MVF-4 as a consequence.

It should be a PrimitiveType with an xsdType of anyURI

anyURI should not be a class

Revised the XMI to change anyURI from uml:Class to uml:PrimitiveType.

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.

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

This is more involved than the FTF wanted to address in the moment, We intend to add more examples in RTF.

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

This issue cannot be addressed until the validator is revised to support canonical XMI.

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

Regenerate Clean XMI from the latest metamodel .mdzip

This does not change the metamodel content as depicted in the previous diagram.

There are no changes to the specification document or other artifacts.

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.

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.