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.
====== Features of the MVF Specification ======

The "major features" are extracted from the usage scenarios.  The detailed features are extracted from the RFP.

====== Major Features =====

The MVF must specify: 

  * an exchange representation for a business vocabulary independent of any model, preferably an existing standard or standards, or a subset thereof

  * a standard form for links between model elements and vocabulary entries.  The vocabulary entries may be selected from a resource (somehow) attached to the model or from a separate resource. Ideally, the linkage should be an additional property for MOF:ModelElement.

  * a standard means for associating other natural language representations of modeling language concepts with the metamodel for the language

  * a standard API for a Vocabulary Service, so that modeling tools can access vocabularies controlled by such services.  Such a service may or may not expose a means of modifying the vocabulary it maintains. Controlled vocabularies may well involve an elaborate review process for modifications.

==== Exchange representation for Vocabularies ====

The MVF should specify (or adopt) a vocabulary metamodel. The MVF vocabulary metamodel must support terms, synonyms, and definitions/formulations identified as to their language, and some means of linking the concepts thus represented across languages. 

The MVF must specify an exchange form for vocabularies that is consistent with the metamodel.

Possible standards:
   * SKOS 
   * SBVR (subset)
   * ISO 11179-3 subset.  Does it have an adopted standard representation?

MVF may specify more than one export/import form for vocabularies.  But there should be a primary form, with optional support for other forms, if any.

[ejb] I expect that the primary exchange form for the vocabulary is (or subsets or extends) some existing standard for that purpose.

==== Links from model elements to vocabulary entries ====

The formal mechanism for the links is an extension to MOF, specifically an association to UML:ModelElement.

The MOF extension needs only to provide for linking model elements to business vocabulary objects/entries, as described in the (to be) MVF specification for vocabulary objects. Each vocabulary entry will be part of a vocabulary that identifies its language and speech community.

The links must necessarily include IRIs, and should not preclude “active IRIs” (service + arguments). Some other form of "local link" may be supported.

Whether a MOF model file may directly incorporate MVF vocabulary objects is an open issue.  

How model elements relate technically to multiple language support is an open issue.  MVF will need to say whether the idea is one model element is linked to one or more vocabulary entries, or one model element links to some instantiated central “concept” object that is in turn linked to multiple vocabulary entries, or one model element links to one vocabulary entry, but that entry is linked to vocabulary entries in other vocabularies (and languages) by some "same concept as" association.

=== Discussion ===

[fac] MVF must define an extension to MOF modeling language metamodels that supports the import and application of multiple vocabularies to the visible elements of the modeling language and to user models -- applications of the modeling language. 

[fac] For import/export, there must be a representation of each concept that is then associated (by the language implementer) to the model or metamodel elements.  This is focused on the single modeling language, shared business model scope. 

[ejb] If the exchange form for the model or metamodel is the XMI form, then the relationship to the vocabulary entries is the XMI representation of whatever the MVF MOF extension is.  If the exchange form for the model is some other form, then the modeling language RTF would have to specify the additions to that form.  

[ejb] The direct inclusion of a vocabulary //within// an exported model is a possible feature of MVF that is listed above as an issue.  Note that it may place an additional burden on MVF implementers who import such model files.


==== Vocabularies for the modeling language (metamodel) concepts ====

[fac] MVF must define an extension to MOF modeling metamodels that supports the import and application of multiple vocabularies to the visible elements of the modeling language and an application of the modeling language. The MVF support for alternative vocabularies must apply to the modeling language concepts as well as applications of the language (i.e., user models) at least for any concepts displayed to the user.  The user should also be able to create a vocabulary that includes these concepts.  

[ejb] We agree that the language metamodel elements can/should be linked to other natural language vocabularies for the those concepts, so as to enable the modeling tool to display modeling language concepts in terms most meaningful to the user.

[ejb] The association of natural language vocabularies to the modeling language concepts is accomplished by using the MVF MOF extension on the model elements of the metamodel (presumably using a UML tool that supports MVF).  The user can use these concepts in his own business vocabulary by adopting (entries from) the vocabulary from the modeling language specification, or some translation of it, in much the same way that UML tools expose the UML metamodel and permit user models to import elements from it. 


==== API for Vocabulary services ====

The actions of maintaining a vocabulary fall under the MVF Service interface. Any tool may maintain vocabularies (in addition to models if they choose).  The Service interface only applies to tools that want to expose those capabilities to other tools.  In general, those will be tools charged with the formal maintenance of business vocabularies.

The RFP calls out many specific capabilities [TBA]

Possible standards and related activities:
  * OMG Common Terminology Services (CTS2) extended
  * OMG API for Knowledge Bases (API4KB) subset

=== Discussion ===

 (I am distinguishing ‘definition object’ from ‘definition by user’ action.)

[fac] I have not addressed the MVF service interface here since there is necessarily a user interface for creating/updating a vocabulary that must be implemented by the language implementer.  It is unlikely that a user will create\update a vocabulary without a model context.  A service interface implies that there is a shared service that goes beyond the simple sharing of XML of vocabularies.

[ejb] I agree only with the last sentence.  Having built models from business documents that introduced and defined terms, and having converted spreadsheets for regulatory vocabulary to SBVR form, I know that business users create vocabularies whilst knowing nothing much about modeling. I think Fred's position is that no user will convert a business vocabulary to a *formal* vocabulary unless s/he is making a matching model, and thus concludes that vocabulary management must be implemented by the modeling tool.  While there is //some// truth to the former, there are counterexamples, especially where multiple views are modeled in the enterprise, it would be very unwise for us to assume that modeling tools will implement vocabulary management, or do it well. We should certainly allow for that case, but also for the case where the modeling tool only imports vocabularies and allows the user to make the links to model elements.  


===== Detailed Features (from the RFP) =====

[to be copied]

===== Optional Features =====

TBD

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

User Tools

Site Tools

Page Tools
