This is an old revision of the document!
All scenarios involve the idea that the model elements of a model (or metamodel) correspond to concepts that have accepted designations and definitions in some stakeholder communities, and those communities may use different natural languages.
We want to support all of these scenarios, but we need to extract from them the MVF content requirements. The rest is usage guidelines. (The RFP describes all these scenarios, but not quite this way.)
The underlying idea is that there are two kinds of tools that support different aspects of MVF:
Some modeling tools can function as vocabulary management tools as well, and may integrate those functions with modeling functions, but that integration is internal to the tool and does not affect the MVF interfaces.
It is also desirable for a modeling tool to present the modeling language concepts in languages appropriate to specific user communities. This is necessarily integrated with the modeling functions, but it does not involve vocabulary management functions in the modeling tool; the translations of the language specification are not created or modified by users, and the terms for the modeling language concepts are internalized in the tool-to-user interface. See the discussion of Scenarios 6 and 7 below.
The user creates the model elements and explicitly provides the terms and definitions for the concepts represented by (some of) the model elements, in one or more languages, using a feature provided by the modeling tool. The modeling tool stores the terms and definitions in its internal model repository and is able to use this terminology in interactions with the user.
This case does not need MVF. The tool would typically export the vocabulary entries and the model element links in a tool-defined “extension” to the standard XMI or XML form for the language.
[fac] I don’t believe you can separate the metamodel MVF capability (your case 6) from this case. The terms of the metamodel will appear in modeling displays and should be expressed in the preferred language (vocabulary) of the user.
EJB> It is closer to Case 7 (do the metamodel vocabulary internally). We agree that it is desirable for a multi-language modeling tool to be able to name and document the modeling concepts in multiple languages, but the capabilities involved are very different from supporting the user in capturing vocabularies and documenting model elements. To a tool builder, there is a “huge” difference between the language you allow the user to create and review and the language in which the tool speaks to the user in menus and dialogs and help files. The tool need not understand Greek to let the user create and use Greek vocabularies, but the tool must itself understand Greek, in some sense, in order to use Greek properly in a dialogue about model elements. And for most modeling tools, there is the further complication of getting the non-English expressions for the technical concepts and their explanations to be technically correct for that speech community. You can't let a “user” change those. So Scenario 1 and Scenario 6/7 are entirely different concerns, even when the same tool can do both.
Like Scenario 1, but the modeling tool can export the model with the business vocabulary entries and links in a form that can be used by other modeling tools, at least for the same modeling language. And the tool should be able to import models with links in that form from other modeling tools for the same modeling language.
This case requires MVF to specify
Unlike Scenarios 1 and 2, the modeling tool can import a business vocabulary that is independently developed and maintained (by another tool) in a standard form, and enable the user to link the model elements to concepts/terms/definitions in the imported vocabulary. In addition, the modeling tool can import and export models with links to externally maintained vocabulary entries. The modeling tool need not be able to create or maintain a business vocabulary; it does need to support user search of the vocabulary. The modeling tool should be able to import more than one business vocabulary, for different speech communities, and link model entries to all of the corresponding vocabulary entries.
This case requires the MVF to specify:
Note that these requirements refine the requirements from Scenario 2.
This scenario combines the capabilities of scenarios 2 and 3 in the modeling tool. The modeling tool can import an existing business vocabulary, enable the user to modify it, or to create new vocabularies, and export vocabularies. The tool can import and export models with model elements linked to the vocabulary entries. The modeling tool itself can act as a vocabulary management tool, more or less independent of any model.
This case requires exactly the same MVF features as Scenario 3.
These cases (from Fred) seem to be about reconciling a user-specified vocabulary with other business vocabularies associated with, or independent of, existing models. They apply to Scenario 4, where the modeling tool also serves as a vocabulary management tool.
EJB> In the general case, the vocabulary to be imported is separate, or separated, from any model. Whether it was originally created by a modeling tool or a vocabulary tool is irrelevant, because the vocabulary itself is a separate resource. We don't want to “embed” a business vocabulary within a model file, regardless of who creates/edits it. By externalizing the vocabulary resource, we can choose to use a standard exchange form.
The vocabulary is for the same model. The user must examine the terms of the imported vocabulary and correlate them with the terms of an existing, internal vocabulary maintained by the tool. The structure of the model will be very helpful if the user can view the sending model and the receiving model for comparison.
EJB> This appears to be the case in which two copies of one model are separately linked to different vocabularies, presumably for different user communities, and possibly in different languages. It is a very reasonable concern. One might expect the modeling tool to add the links from the second vocabulary to the corresponding model elements, however that is done. I don't understand what other kind of correlation is required. The alternative seems to be some kind of vocabulary merging activity in vocabulary management tooling, which is not an MVF concern.
The imported vocabulary is from the same business domain/discipline/enterprise but is linked to a different model in the same modeling language. Some of the concepts may be shared by the two models, and links from the active model elements can point to the matching concepts, so alignment for these will be simplified.
This could be used to develop a unified vocabulary for a business domain, combining the existing, internal vocabulary with the imported vocabulary to create a reconciled vocabulary. However, since the models are not the same, differences in the semantics of model concepts may be more difficult to recognize.
EJB>This is a special case of C below. It is based on the idea that the imported business vocabulary was created with a specific model, and that the vocabulary is somehow exported with that model. The vocabulary is useful to the user, but the model is not the model the user wants to work on. The vocabulary has to be a separable import in one way or another. It must be possible for the modeling tool to extract that vocabulary and treat the other model as separately linked to it. That is, the user wants to work on M2, so s/he imports (M1+V) and then works on M2 and V, ignoring M1.
EJB>There is also the special case where the user wants to work on M2, and M2 imports M1. So the user will extend the “total” business vocabulary and possibly override some of its terminology. But that “override” will require some vocabulary technique that falls under “context”. In vocabulary terms, the business vocabulary for M2 may be a separate vocabulary that “adopts” the imported business vocabulary, or the user may just extend M1.
The imported vocabulary is not for a model created with the same modeling language, but it is for the same business domain/discipline/enterprise (if the domain/discipline/enterprise is not the same, then reconciliation of semantics will be even more difficult).
EJB> This is the general case – the relationship of the vocabulary to other models is irrelevant to its use. Some issues:
The imported vocabulary is a “universal” vocabulary or set of vocabularies for a set of universal concepts. The user must reconcile concepts based on natural language semantics of terms and definitions in both the internal vocabulary(s) and imported vocabulary(s). The existence of this universal vocabulary might evolve from efforts of standards or professional organizations, but it represents a major investment and years before it provides business value to users.
A “universal” vocabulary might be more useful if it is supported by a concept taxonomy that enables a user to find appropriate general concepts leading to needed specializations or add specializations as needed in order to reconcile the internal concepts with the imported concepts. However, given that the concepts can be identified and appropriately specialized, there is still a major investment in many vocabularies for subsets of the concepts to reflect terms/designations for different communities (different natural languages, different disciplines, different enterprises).
The vocabularies include semantic formulations in a standard, formal language so that corresponding concepts can be automatically identified.
This is treated below as a separate topic.
This scenario is like scenario 3 on the model management side, but the business vocabulary is not available for import. It is controlled by a service that maintains it and does not export it, but rather provides interfaces for accessing concepts, terms and definitions for different speech communities. The modeling tool provides user access to the vocabulary services and enables the model elements to be linked to vocabulary items as maintained by the service. The modeling tool can import and export models so linked.
This case requires MVF to specify
[fac] This is Case 3(e) with the universal concepts and vocabularies provided by a service and therefore an enterprise that has made the investment and realizes business value by providing the service with mechanisms to prevent unauthorized copies.
The “business vocabulary” is extracted from the language specification in the standard form (somehow). A UML/MOF tool provides (per Case 2, 3 or 4), for linking the metamodel elements to the specification vocabulary elements. In addition, translations of the specification vocabulary to other languages may be constructed and exported, and a UML/MOF tool may import them and link the metamodel elements to the corresponding vocabulary items. A modeling tool can import the metamodel with the links and use the multiple language terminologies in dialogues with the user.
This case requires the same MVF features as Case 3.
[fac] The tool provider(s) (or the metamodel submitters) should provide the vocabulary of the modeling language specification (terms and definitions from the spec). Tool vendors (or vocabulary vendors) may provide alternative vocabularies for the metamodel. This reduces the user burden and should have market value at least for the tool vendors.
[ejb] The model element linking really must be done by a tool that can export a metamodel, ergo, a UML/MOF tool. Yes, the vocabulary and links should be provided by the submitters of the metamodel. The problem with alternative vocabularies for the metamodel is to ensure that a version of the standard in some other commercial language is a proper translation that matches the intent of the original. If tool vendors do this themselves, to improve their customer experience and their market, it can get legally and politically messy. This should already be an OMG issue, as it is an ISO issue.
Same as Scenario 6, except that the tool that maintains and links vocabularies to the metamodel is not a general-purpose UML/MOF tool, but rather a tool that internalizes a specific metamodel. Such a tool is essentially an adjunct to a modeling tool for that specific modeling language.
This case may require nothing but proprietary capabilities, but for exchange purposes, if that is wanted, it requires the same MVF features as Case 4.
[fac] I'm not sure what this means. The modeling language implements the metamodel and should be able to link to vocabularies for the metamodel the same as for models created by the user.
EJB>The presumption of Scenario 6 is that the non-English vocabulary for the language specification is created using some vocabulary facility and linking the vocabulary to the MOF metamodel for the language using a UML or MOF tool (a general-purpose metamodeling tool). Scenario 7 just says that some BPMN vendor could create a Spanish translation of BPMN specification concepts and link it to the vendor's internal tooling for BPMN. This is “do the metamodel vocabulary inside the tool”.
As worded above, the only link between the terms and definitions for the same concept in multiple language vocabularies is the model element (which would satisfy the RFP intent). It should, however, be possible in creating and maintaining vocabularies to make such links as annotations to a vocabulary entry, and then to include those links in the exported vocabulary file.
[fac] Note that for a particular modeling language, vocabularies will likely be shared as defined for existing models. A user will either import a model with vocabularies and then modify the model, adding needed concepts, or will import the vocabularies and use the existing model for reference to reconcile to the shared concepts.
[fac] Case 3(e) the vocabularies include semantic formulations in a standard, formal language so that corresponding concepts can be automatically identified. This would be great, but it requires vocabularies for the formal language elements and additional concepts for the elements needed for precise formulations. This represents a substantial investment for specification of formulations and associated vocabularies. Maybe SMIF will address this. Once the formulation language and concepts are established, then the formulations for individual concepts must be specified. This is not likely to be a task for typical users of the modeling tools, and there must be business value realized by the developers of these formulations.