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.

Alternative vocabularies may represent different domains of discourse in the same or different natural languages.

MVF vocabularies must support homonyms that have different meanings in different contexts of use.

MVF must support multiple different designations (terms, captions, expressions) for the same concept.  

[fac] However, a single vocabulary may support only one designation and synonyms would be designations in alternative vocabularies.

[ejb] A single vocabulary may contain synonyms (multiple designations) for the same concept.  It may be necessary to provide a "primary term" feature that guides the modeling tool as to what term to present to the user.

It must be possible to define a vocabulary as a specialization of an existing vocabulary.  The new vocabulary implicitly contains all the terms and concepts from the existing vocabulary, and may add additional concepts, terms, and definitions, and/or define synonyms for selected concepts.  It may also change the "primary term" for an existing concept.  (This is the SBVR "vocabulary1 adopts vocabulary2" concept.)

It must also be possible for a new vocabulary to adopt selected entries (concept, term, definition) from an existing vocabulary //without// adopting the entire vocabulary (and thus possibly creating terminology conflicts).  This might take the form of a copied entry with some kind of pointer to the original, or it might just be a/the term for the same concept in the new vocabulary (that happens to be the same term).

[fac] If a given concept has more than one synonym in the same vocabulary, then a secondary user of the language and vocabulary will get the primary synonym unless they specifically identify that they want an alternative designation for each such concept.  A secondary vocabulary could incorporate the primary vocabulary and only include specific terms/synonyms, so the secondary can select to use those designations. 



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

[fac] Within the scope of a single model (a particular application of a given modeling language), each of the concepts in that context must be represented and defined as the basis for identification of the designations (terms, captions, expressions) that will appear in displays and represent the associated concept in user inputs.

[ejb] It must be possible for the user to link the model elements to vocabulary entries: terms, definitions, and other annotations.  Clearly the modeling tool must be able to display these to the user.  Beyond that, MVF cannot //require// any user interface capabilities of the modeling tool.

[fac] MVF vocabularies must support homonyms that have different meanings in different contexts (name spaces) of the same modeling language or application model. 

[ejb] That is, a model element is linked to vocabulary entries for the same concept. A given term may refer to different concepts in different vocabularies.  In a single vocabulary, a given term may refer to different concepts based on context of use. This means that a model element must link to the concept (however that is represented) rather than to a term "out of context". 

[fac] The sharing of vocabularies across different modeling languages would require that the vocabularies be based on a superset of the concepts of the modeling language metamodels and the concepts of interest in the business domains of the language application models. Sharing across different modeling languages (and consequently different user/business models) necessarily involve reconciliation of a superset of both language and application concepts.  

[ejb] "Sharing" vocabularies (or selected entries) across different "application" models only requires that the model elements represent the same business concept. The modeling concepts can be very different, emphasizing different aspects or uses of the business concept. The link between a model element and a vocabulary entry is "model element //represents// business concept" in the model; the model element //is not// the business concept. A UML Class and a BPMN Activity are different "classifiers", but they can represent the same business concept.  (It may be true of VDML that the business concepts are intertwined with the metamodel concepts, but that is not true of UML or DMN or SOAML; it is only true of SysML and BPMN at a very high level of generality; and the modeling concepts in data models don't match the business concepts at all, because the data elements are just representations.)  Sharing concepts across language metamodels is a separate concern, discussed below.

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

[fac] The sharing of vocabularies across different modeling languages would require that the vocabularies be based on a superset of the concepts of the modeling language metamodels and the concepts of interest in the business domains of the language application models.

[ejb] The modeling language concepts to be shared should be documented in their specifications, or in some other reference.  Both may involve specialization in the use of a shared term that is adopted from some other (more general) vocabulary. In most cases, the concepts in a modeling language are several levels of abstraction above the business concepts they can be used to represent, and some have no relationship to the business concepts at all.  In general, the business domains of the language applications are irrelevant to the metamodel concepts.  Just look at the wide range of uses of BPMN and UML.


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

[fac] 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 =====

==== support for formal language formulations ====

[fac] Integration of vocabularies for different modeling languages and different language applications (user models) could be facilitated by concept definitions expressed in formal language formulations.  However, this requires (1) concepts and vocabulary for the expression of the formalisms, and (2) the efforts of experts to express the formulations for each of the concepts.

[ejb] MVF should support the idea that a concept can have a formulation in a formal language in addition to formulations (definitions) in natural languages.  The model probably looks very much the same, that is, there is a "vocabulary" with terms (symbols) and definitions (formal formulations) that is for the formal language rather than for a natural language. It is yet another set of representations of the concept. The language designation for the "vocabulary", however, won’t have an ISO language code. And the tool would only present this vocabulary to the user on specific request.

===== Suggested Features =====

(items can be moved from this list if there is agreement)

==== Concept taxonomy ====

[fac] When a user is creating a vocabulary, the user must locate the concept element that represents the concept of interest or determine that the concept is not yet represented.  This should be facilitated by support for a concept taxonomy so that a search can proceed from general concepts to more specific concepts.

[ejb] The concept taxonomy stuff is way out of scope for MVF.  If the user creates a model element for a business concept, then s/he knows some preferred term for that concept.  If that term is not in their reference vocabulary, it has to be added, and it may or may not refer to a concept that is already there under another term.  How the user can find a concept for which s/he does not know the search term is a vocabulary tool issue we do not want on the MVF plate.

[fac] I disagree.  If a user is creating a model and has the benefit of a vocabulary created for a different model then the user will be defining new concepts not relevant to the earlier modeling application.  So the user needs some ability to find a concept of interest if it already exists.  The user may also need to refine the definition of a concept that exists and is similar but must be differentiated.  This begs for support of a taxonomy.

[ejb] So, if MVF specifies for the API the ability to find a concept by something other than the term the user uses for the concept, how would you describe the interface element?


==== Evolution of vocabularies ====

[fac] The development of vocabularies should go through a process of evolution starting with (1) individual enterprises that need to share models of a single modeling language with activities that prefer different natural languages, (2) possibly expanding to concepts and vocabularies across different modeling languages for the same enterprise, (3) development of concepts and vocabularies developed by professional groups for specific business domains, and (4) to development integrated, concept supersets and associated vocabularies developed by an interdisciplinary, business standards organization.  Each level of evolution will be driven by different business values and increasing levels of effort and collaboration.  MVF should 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.

[ejb] I’m not sure I agree with this model of vocabulary evolution, partly because industry-wide reference vocabularies for several business domains already exist, and would need only to be captured in an MVF-compliant form/tool.  And once tool support for a standard exchange form exists, take-extend-adapt will also be a common development approach.

[fac] if these vocabularies are defined for multiple natural languages, that is a useful starting point, but when we talk about concepts in models, the definitions frequently are not sufficiently distinct and thus the user will need to clarify the definitions, possibly multiple definitions for variations on a single concept.

[ejb] This view is model-specific:  In my model, I use this business term to mean this business concept seen from my viewpoint and ignoring what else it may mean to other elements of the enterprise.  But does my model element represent all of the same "things of the business" that the business term and definition denote?  That is the question.  If it refers to a clearly different set of things, the model element represents a //different// business concept.  If it represents the same set of things, as best one can determine, then the model element can link to the established concept, and any narrow aspect that is important to my model is just an annotation for the model element. The purpose of MVF is not to split hairs about definitions; it is about facilitating communication via the model.  The links to business concepts do not have to be exact matches to serve that purpose.  Again "model element represents business concept", i.e., stands in for that set of "things of the business", is the relationship.  Conversely, if I develop the "business vocabulary" to match exactly the thinking in my model, it will never be shared, because of my narrow view, and the issues about translation to other languages will multiply, because they too must be just as narrow.

[ejb] We have very different views of MVF.  In my view, business vocabularies and concepts are shared across multiple units and aspects of an enterprise, or among multiple participants in a joint enterprise, by (loose) agreement.  Models relate to those concepts.  Fred's view seems to be that the "business vocabulary" is created by the modeler, and the MVF is about translating the model documentation into Japanese. Can the MVF support both views? 




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

User Tools

Site Tools

Page Tools
