MVF RFP Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== MVF Compliance Points ======

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

  * [MVFIMP] import vocabularies in the primary MVF exchange form
  * [MVFEXP] export vocabularies in the primary MVF exchange form
  * [MVFXMI] link model elements to vocabulary entries and import and export the corresponding XMI model files
  * [MVSVC1] provide the basic MVF service interface
  * [MVSVC2] provide the complete MVF service interface
  * [MVCLI] function as a client of the basic/complete MVF services

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] imports business vocabularies in one or more languages, provides for user-specified linkage of model elements to vocabulary entries in one or more languages and uses the appropriate terms and definitions in interactions with the user; implements MVFIMP; implements MVFXMI.
  * [MODELM] in addition to MODEL1, imports multi-language vocabularies associated with the metamodel for the modeling language supported by the tool and can interact with the user using those terms and definitions.
  * [MODELC] in addition to MODEL1, implements MVCLI for access to terms and definitions.

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:
  * [VOCAB1] provides for user creation and modification of vocabularies in one or more languages; implements MVFEXP.
  * [VOCAB2] in addition to VOCAB1, implements MVFIMP and allows the user to modify an imported vocabulary, copy entries to other vocabularies, and link vocabulary entries (in different languages) across vocabularies. 
  * [VOCAB3] in addition to VOCAB1, implements MVSVC1, providing read access to vocabularies it maintains. (Access and/or export may be controlled.)
  * [VOCAB4] in addition to VOCAB2, implements MVSVC2, providing for write access to vocabularies it maintains.(Access and/or export may be controlled.) 

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.

===== Discussion of view and compliance structure =====

[fac] The development of vocabularies should go through a process of evolution starting with
  - individual enterprises that need to share models of a single modeling language with activities that prefer different natural languages, 
  - possibly expanding to concepts and vocabularies across different modeling languages for the same enterprise, 
  - development of concepts and vocabularies developed by professional groups for specific business domains, and 
  - development of integrated, concept supersets and associated vocabularies developed by an interdisciplinary, business standards organization.  

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


===== Discussion of Compliance Point xxx =====


----
[[http://www.omgwiki.org/mvf-rfp/doku.php?id=start|home]]
MVF RFP Wiki

User Tools

Site Tools

Page Tools
