Multiple Vocabulary Facility Avatar
  1. OMG Specification

Multiple Vocabulary Facility — All Issues

  • Acronym: MVF
  • Issues Count: 11
  • Description: All Issues
Closed All
All Issues

Issues Descriptions

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

  • Key: MVF-21
  • Status: closed  
  • Source: Coventry University ( Mr. Stephen Powley)
  • Summary:

    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)

  • Reported: MVF 1.0b1 — Wed, 7 Jun 2023 22:54 GMT
  • Disposition: Deferred — MVF 1.0
  • Disposition Summary:

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

  • Updated: Sat, 2 Mar 2024 23:59 GMT

The MVF ontology is missing the class "MVFElement"


The property, isRelatedTo, on which the MVF ontology depends has been removed from Commons and must be re-created in the MVF ontology

  • Key: MVF-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: MVF 1.0a1 — Thu, 1 Sep 2022 16:28 GMT
  • Disposition: Resolved — MVF 1.0
  • Disposition Summary:

    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.

  • Updated: Mon, 2 Oct 2023 12:57 GMT
  • Attachments:

The property, hasMVFEntry, is used too broadly in the MVF ontology

  • Key: MVF-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: MVF 1.0a1 — Fri, 13 Jan 2023 19:28 GMT
  • Disposition: Resolved — MVF 1.0
  • Disposition Summary:

    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.

  • Updated: Mon, 2 Oct 2023 12:57 GMT
  • Attachments:

Need a profile for the MVF metamodel in order to better integrate with various other UML profiles and tools

  • Key: MVF-4
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: MVF 1.0b1 — Fri, 27 Jan 2023 19:32 GMT
  • Disposition: Resolved — MVF 1.0
  • Disposition Summary:

    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.

  • Updated: Mon, 2 Oct 2023 12:57 GMT
  • Attachments:

UML Profile for MVF

  • Key: MVF-7
  • Status: closed  
  • Source: Mayo Clinic ( Dr. Davide Sottara)
  • Summary:

    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

  • Reported: MVF 1.0a1 — Fri, 31 Mar 2023 18:47 GMT
  • Disposition: Duplicate or Merged — MVF 1.0
  • Disposition Summary:

    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.

  • Updated: Mon, 2 Oct 2023 12:57 GMT

anyURI should not be a class

  • Key: MVF-15
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It should be a PrimitiveType with an xsdType of anyURI

  • Reported: MVF 1.0a1 — Mon, 15 May 2023 20:43 GMT
  • Disposition: Resolved — MVF 1.0
  • Disposition Summary:

    anyURI should not be a class

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

  • Updated: Mon, 2 Oct 2023 12:57 GMT
  • Attachments:

Clarify uri vs refrence vs externalReference

  • Key: MVF-6
  • Status: closed  
  • Source: Mayo Clinic ( Dr. Davide Sottara)
  • Summary:

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

  • Reported: MVF 1.0b1 — Fri, 31 Mar 2023 18:42 GMT
  • Disposition: Resolved — MVF 1.0
  • Disposition Summary:

    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.

  • Updated: Mon, 2 Oct 2023 12:57 GMT
  • Attachments:

More examples are needed to demonstrate how to use MVF

  • Key: MVF-3
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: MVF 1.0a1 — Fri, 13 Jan 2023 19:35 GMT
  • Disposition: Deferred — MVF 1.0
  • Disposition Summary:

    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.

  • Updated: Mon, 2 Oct 2023 12:57 GMT

The published XMI should be generated as Canonical XMI

  • Key: MVF-8
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: MVF 1.0a1 — Fri, 14 Apr 2023 18:18 GMT
  • Disposition: Deferred — MVF 1.0
  • Disposition Summary:

    The published XMI should be generated as Canonical XMI

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

  • Updated: Mon, 2 Oct 2023 12:57 GMT

XMI document is missing class "MVFEntry"

  • Key: MVF-5
  • Status: closed  
  • Source: Mayo Clinic ( Dr. Davide Sottara)
  • Summary:

    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

  • Reported: MVF 1.0a1 — Fri, 31 Mar 2023 18:29 GMT
  • Disposition: Resolved — MVF 1.0
  • Disposition Summary:

    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.

  • Updated: Mon, 2 Oct 2023 12:57 GMT
  • Attachments: