MVF is unusual in that it identifies interfaces and capabilities for two different kinds of tools – modeling tools and vocabulary management tools. There are compliance points that might apply to either, but there are also compliance points that apply only to modeling tools or only to vocabulary management tools.
The following are the currently proposed compliance elements (which may become detailed compliance points):
MVF may specify additional possible exchange forms (corresponding to existing standards), and support for import and/or export of these, in addition to the primary form would be additional compliance points.
MVSVC1 and MVSVC2 are called out in the RFP.
There are several potential levels/aspects of compliance by an MVF-conforming modeling tool:
MODEL1 is suggested minimum compliance for a modeling tool. MODELM and MODELC are separate additional compliance points.
There are also several potential levels/aspects of compliance by an MVF-conforming vocabulary tool:
The compliance points for vocabulary management may be viewed as levels of compliance, except that it may be possible to comply with VOCAB3 without complying with VOCAB2. That is, providing access to a particular controlled vocabulary would not require the ability to import others and create cross linkages.
Some modeling tools may elect to support both MODEL1 and VOCAB1 or VOCAB2, making them hybrid tools.
[fac] The development of vocabularies should go through a process of evolution starting with
[fac] Each level of evolution will be driven by different business values and increasing levels of effort and collaboration. MVF should support this evolution without increasing the cost and level of collaboration beyond that required at each level of evolution. This might be addressed by different levels of compliance. MVF must recognize these levels of evolution as corresponding to the evolution of the market and thus the business opportunities for language implementers and vocabulary developers.
[ejb] Fred's view seems to be that only a modeling tool will comply with MVF, and he describes the evolution of the market for modeling tools that act as vocabulary managers. This ignores the fact that formal industry vocabularies and vocabulary management tools already exist in the enterprise marketplace.
[ejb] These compliance points are what the tool can or cannot do as a system component. MVF is not a modeling language standard with “levels of compliance” as ever larger sets of modeling capabilities. It is a standard for making a system by linking two previously unrelated capability sets. Modeling tools and vocabulary tools can do entirely different things and still conform by importing and exporting MVF vocabularies, but only modeling tools can import and export linked models. Only a vocabulary management tool can support service interfaces [MVSCx], and only a modeling tool has any reason to support [MVCLI]. A modeling tool that moonlights as a vocabulary management tool can do it all, but may choose to support only [MODEL1] and [VOCAB1]. But whether it can do it all or not, I may restrict its role in my system to ‘xxx modeling tool’. These compliance points enable roles. The compliance levels below represent levels of capability in each role, but that is about details of support for the role.
Recommendations for changes to structure?