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.

he 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]]

====== User Features =====
July 29, 2017 Draft by Fred Cummins

The following features are intended to reflect a user’s perspective on an implementation of the MVF specification.  
The purpose is to develop a consensus on the features that should be supported (or enabled?) by the MVF specification.

1.	Vocabulary.  A vocabulary is a set of terms/designations that express the concepts of modeling language metamodel(s) and user model(s) in an associated natural language as appropriate to a community of developers and/or users of modeling language(s) and/or user model(s).

**Use Case**.  Users will select a vocabulary for interaction with the modeling environment and some users will create or update specific vocabularies. A vocabulary may be shared as a unit or as a member of a package.

a.	A new vocabulary may reference another vocabulary to specify terms such that a new vocabulary may delegate for terms it does not address, define specialized concepts for certain terms and add terms for additional concepts thus reducing the work required to define a vocabulary for another community of discourse.

**Use Case**. A user/community may be happy with an existing vocabulary but prefer that certain terms be modified.  This allows a new vocabulary to be created that "inherits" the terms of the existing vocabulary and then the selected terms can be modified without affecting the existing vocabulary.

b.	The vocabulary will specify a vocabulary name and version. 

**Use Case**.  This is information for users to reference and manage updates to vocabularies.  An independent user may revise a vocabulary that other users may or may not wish to use.

c.	A vocabulary will specify the community(S) of discourse for which the vocabulary is intended. Community names should be in the natural language associated with the vocabulary. 

**Use Case**.  This information is for users to identify a vocabulary of interest.  __There may be multiple communities shown to be recognizable by potential users.  
__
d.	A vocabulary will specify a natural language that is the basis for the terms/designations specified by the vocabulary. 

**Use Case**. This is also to assist in user identification of a vocabulary of interest.

e.	A concept that specializes a concept in a referenced vocabulary will have a link to the source concept to clarify the distinction and support the conversational use of the less specific term (may be expressed in the same or different term depending on the community and/or natural language). The source concept may be associated with multiple specialized concepts in different vocabularies or for complementary concepts in a single vocabulary. NOte that these concept relationships have implications to the management of vocabulary updates.

**Use Case**. If vocabulary B is based on vocabulary A, but a more specific definition is needed for vocabulary B, this provides reference to the more general concept and the association may be the basis for a concept taxonomy to help a user locate a desired concept.  This is particularly relevant when the source vocabulary (vocabulary A) is a vocabulary of business terms.

f.	A vocabulary will specify an owner (person or organization) that is responsible for managing changes. 

**Use Case**. There may be shared vocabulary users in different departments or companies.  Updates should be coordinated if not validated. 

**Use Case**. Vocabularies will evolve and this evolution must be managed to support multiple users of the vocabulary that may be indifferent organizations or companies.  If there are problems with a vocabulary, they should be resolved with the owner.  The owner would potentially keep track of the users to provide updates and potentially collaborate on changes.

2.	Vocabulary package/library. One or more vocabularies may be managed as a package or library of vocabularies to exchange and maintain together.  

**Use Case**. vocabularies should be packaged for convenience in sharing.  In addition, there is a need to reconcile concepts of multiple vocabularies for use that may involve some human participation.  These reconciled concepts should be preserved by the package.

a.	A concept has only one representation within a package/library or in an operational, MVF-supported modeling environment.

**Use Case**. A model element must be linked to the MVF Entry that represents the model element concept.  If concepts of different vocabularies are not reconciled, then there should be multiple links from the model element for the different vocabularies.  The multiple links effectively identify a shared concept. This would also require identification of the multiple links for other occurrences of the shared concept in the same and other models using the same vocabularies (package). 

b.	A mechanism will assist with reconciliation of concepts when merging vocabularies from independent sources (i.e., concept identiriers are different for the the same concept from different sources).

**Use Case**. The use case for item a, above describes the need for this facility.

c.	a package/library or selected vocabularies can be imported/exported as XMI.

**Use Case**. A package should preserve the reconciliation of concepts for multiple vocabularies so reconciliation need not be repeated.

d.	A modeling tool may have a complementary library for the metamodel and other tool-specific concepts.

**Use Case**. A tool provider will provide tool-specific vocabulary(w) for customer satisfaction. A tool-specific vocabulary could provide translation of terms/captions that are incorporated in the user interface but are not associated with the model or metamodel. 
		
e.	A separate vocabulary package/library may be defined for the terms/designations required for a modeling language.  

**Use Case**. This vocabulary or package of vocabularies may be created/adopted as part of the language specification for consensus, consistency and efficiency.

f.	A package must include any vocabularies that are referenced by vocabularies specified to be included in the package.

**Use Case**. This is addressed in Use Case 1(a), above.

3.	Terms/designations.  Terms/designations are character strings associated with a vocabulary to express modeling concepts in inputs (such as data entry forms) and outputs (such as displays) for a modeling language and user model(s).

**Use Case**. 

a.	Terms may be words or phrases, including spaces and special characters that appear in place of the concept names of the metamodel and user model in displays and may be used for user input to designate the associated concepts.

b.	Terms may be phrases that express the intent (concept) of a display caption, query or command displayed to the user to provide information, require a decision or request an input.  This might be an optional compliance point.

c.	There are two fundamental “categories” of terms as concept identifiers: (1) a term that is an identifier of a specific model element or specific elements in different contexts (see also Name Space), for example the “Edit” activity name may refer to different activities in different processes, and (2) a term that identifies an instance of a class or type of element and has the same meaning in multiple contexts, for example, an “Activity” is an instance of a BMPN metamodel Activity class and is the type of an object that occurs in many processes so the.  Note that the Activity class concept is not the same as the Activity instance concept.

4.	Business vocabulary.  A vocabulary of generally accepted business terms.

a.	A business vocabulary appropriate to the modeling business domain may be imported as a starting point for modeling terms. A vocabulary that is more specific to the modeling requirements may incorporate these terms by reference and create more specific definitions of terms or provide additional terms.

b.	Business vocabularies should come with standard concept identifiers.

5.	Synonyms.  Users can use and view terms that are familiar and meaningful to them but those terms may not be the desired terms of other users that share the same spoken, natural language. Three alternatives:

a.	A vocabulary may have multiple, alternative terms (synonyms) for entry of a reference to a model concept, but only a preferred synonym will appear in outputs for a particular concept.

b.	A vocabulary may have multiple, alternative terms for input and display that reflect the preferences of a particular sub-community

c.	Synonyms of terms in a primary vocabulary are defined in a specialized vocabulary for another community and default to remaining terms specified by the primary vocabulary.

6.	Concept.  A concept represents the meaning of an element of a modeling language metamodel and/or user model(s) element.  An appropriate term for a concept is selected from the concept entry of a user-designated vocabulary.

a.	Concepts include classes and instances, attributes, associations, and enumerated values of metamodels and models.  

b.	A concept may represent the meaning of a caption, statement or query that appears in a display to support interaction with a modeling language. A display of a computed value could have a caption that is not a model element, but an element of the display.

c.	A concept is the basis of a link between a metamodel or model element and the terms/designations of alternative vocabularies that express the concept in outputs and inputs.

d.	A concept may have identifiers for different vocabulary management domains.  Vocabularies may be managed by an individual, a department, an enterprise or an external vocabulary management service.  

e.	Concept identifiers for a modeling language metamodel are defined for the modeling language specification,

f.	MVF applies to representations (examples) of instances of user model elements

7.	MVF applies to modeling language extensions (Ref: BPMN, UML profiles?)Concept definition.  A concept definition is a natural language expression of the meaning of a concept.

a.	A concept may not have a definition if the term(s) that express the concept are self-explanatory.

b.	A definition for a metamodel concept should come from the specification of the modeling language metamodel.

c.	Concept definitions may be assigned to each associated term/designation, expressed in the natural language of the term/designation and/or the associated vocabulary.

d.	Concept reference links may provide access to external definitions of the concept.

8.	Concept search support.  Vocabularies that have been developed independently must reconcile their concepts when used together so that a concept will be properly expressed when different vocabularies are selected by users.

a.	. Support for a taxonomy of concepts could help a user find the appropriate designation of a concept.  

b.	Support for a directory of similar concepts (thesaurus?) could also help a user find the term for a specific concept.  

c.	Either of these techniques would require additional vocabularies(?) and relationships,

9.	Name space.  A name space distinguishes the meaning (concepts) of certain terms that that occur within the scope of a containing model element.  

a.	A name space applies to elements of particular classes or types that are contained by an element of a particular class or type. The concepts of the terms for the contained elements are distinguished from not-contained 
element concepts that may be identified by the same terms.   For example, the attribute names of a class must be unique within the class but need not be unique in a broader context. 

b.	Not all elements within the scope of a name space are specialized by the name space.  Those affected are distinguished by their type/class.

c.	What determines the depth of scope of a name space?

d.	Name space specifications must be specified for the modeling language metamodel and the models it is used to create.  For example, metamodels will have name spaces defined by MOF (UML), but the modeling language metamodel defines name spaces for the user models.  For example, the BPMN metamodel determines that activities have unique names within a process.

e.	Terms for elements in a name space can be presented as qualified by the term for the name space containing element.

10.	Context of use.  A concept associated with a term may be dependent on the context in which the term is used.  A vocabulary is a context of use, and a name space is a context of use, but there may be other relevant contexts. Note that context of use may be dependent on the associated natural language where a term in one language may have a specific meaning, but the same concept in another language may be expressed by a term that has alternative meanings in different contexts. 

a.	A context of use could apply to an integrated/composite vocabulary where the concepts for terms depend on the modeling language.  However, this could be addressed with additional, modeling-language-dependent vocabularies.

b.	Context of use would apply to discourse outside the scope of MOF modeling.  This would require a mechanism for identification of the context.

c.	A sub-community of users could define a context of use for terms for specified concepts. 

11.	Multiple users.  Multiple users, interacting with a shared modeling environment, may select different vocabularies.  Optional compliance?

12.	Dynamic vocabulary selection.  A user may dynamically change the vocabulary selection and obtain displays in the new vocabulary by display refresh and for subsequent displays.

13.	Concept alternative terms.  A user can request a list of the terms (and associated vocabulary) for a particular concept].	

14.	XMI selectable vocabulary. XMI may be exported with the terms defined by a selected vocabulary.  This allows a MVF-supported model to be imported to a non-MVF modeling environment with terms from a selected vocabulary.
MVF RFP Wiki

User Tools

Site Tools

Page Tools
