This page discusses the implications of context-dependent terms in the different sub-cases described under Scenario 4 in the MVF Wiki.

Within a particular (user) model, there may be duplicated terms for which the meaning (i.e., the concept and definition) depends on the context in which the term occurs. For example, activities in different processes may have the same names (terms) but are not the same thing. Or an attribute may have the same name in different classes or may be the name of a class of object.

The distinction depends on the element that represents the context in which the term is used. The process element for the activity, and the metamodel class of the attribute/class name.

As long as vocabulary is for a single model, the context is determined by the modeling language that must recognize the differences in name spaces. A context-based element in a model will be associated with another element that identifies the context/name space.

Here only some of the concepts/meanings of elements of the user’s source model are not the same as concepts in the target model while some of the same terms may represent the same or different concepts or contexts. Essentially the source and target models initially are the contexts for the terms.

Each vocabulary associates each concept with the term for that concept in that vocabulary. The challenge is to identify the concepts that are the same in both the source and the target models starting with concepts that have the same name/term in the source and target models. Those source concepts that are NOT in the target vocabularies may be added to the corresponding target vocabularies for future reference. Those that are the same may or may not be expressed with the same terms in the corresponding source and target vocabularies. If the terms for the same concept are not the same, then the user may determine which term is more appropriate, or it may be necessary to define the terms as synonyms, or it may be more appropriate for the source and target to use different vocabularies.

The user must determine which concepts have the same meaning in the source and target vocabularies. Note that a concept only occurs once for a vocabulary set (e.g., source or target) for which each vocabulary defines a term that expresses that concept. The user may use the concept definitions to consider if source and target concepts are the same. In some cases, it may be necessary to recognize that two concepts are similar but different so that they must have different terms in each vocabulary with the difference clarified in their definitions. It would be helpful if each vocabulary set had a form of taxonomy of concepts that might suggest which concepts may be the same.

Effectively, the source and target models may be considered different name spaces until the vocabularies are resolved. Each model may also have elements in contexts/name spaces as identified in the first sub-case, A, above.

[ejb] A business vocabulary that is used for multiple models is conceptually independent of all of them. That is, this situation (B) is equivalent to situation (C) for this issue. Finding the business concept for a given model element does not have anything much to do with what other model elements, if any, it was used for, although that might be a means available to some users with some tools. We must presume that the user knows some business term for the concept s/he wants the model element to represent. If the business vocabulary contains terms that have different meanings in different contexts, s/he has to find the term and the several contexts and meanings and identify the intended concept. The model element must be able to refer to the “business concept” and/or to the “term in the business context” as a means of reference to that concept. It is the “term in the business context” and its definition that has translations into other languages.

In this case, the user is creating a model and is using an existing vocabulary or set of independently developed vocabularies as the basis for definition of concepts and terms for the new model. Note that if the user already has a model, then the elements already have terms of an implicit vocabulary, and the challenge is the same as for case B, above.

As the user creates model elements, s/he must look in the imported vocabulary for a concept definition that is appropriate for the model element. For some elements, a concept may be already defined, and thus the term for that vocabulary is defined. For some other elements, there will be no equivalent concept, so the user must create and define a new concept and a term in the user’s preferred vocabulary. For many elements, there will be a concept that is similar but not quite appropriate, So the user must define a new concept and definition that is distinct from the exiting concept definition. This may require clarification of the existing concept definition.

If a term is context dependent, the context specification may be dependent on the modeling language. I this case, the user must determine if there is an equivalent context in the model being developed. This may require an understanding of the context as defined in the source model(s). If the context is not equivalent, then the user may need to define a vocabulary in which the term ambiguity is resolved by a different context reference. It is probably necessary to define a form of context/name space specification that is independent of modeling language. This might be addressed by name-space concepts.

Some elements may be members of a class or type, so the class or type must be represented by a concept and associated definition. Here there may be some member elements that are appropriately described by an existing concept, but the user must ensure that the existing concept definition applies to all members of the class or type, or a distinct concept and definition may be needed for one or both the original; and new concepts.

[ejb] The “business context of use” of a term cannot possibly be “dependent on the modeling language”. The modeling language concepts are either utterly independent of the business concepts or directly mirror some business concepts. But it must be business concepts that form the “business context of use” of a term.

The goal of this case is to define a set of concepts and definitions that have broad application and an associated set of vocabularies that include a number of natural languages and specialized domains. As a practical matter, there must be a clear definition of scope of the concepts and the associated, diverse communities of discourse. Most likely, vocabulary sets will emerge by industry or business discipline, based on business demand.

If a user has access to a set of vocabularies for his/her industry or business discipline, and that includes a vocabulary for their primary language and discipline, then the challenge is to find each concept using terms in the user’s primary language (and business domain) so the vocabulary set will make available terms for that concept in other languages. The user will need search support for their preferred vocabulary, perhaps like a thesaurus. If there is no appropriate concept then the action is equivalent to sub-case C, above.

Similarly, if a term is context-dependent, and the context (I.e., name space) is not the same in different domains, then in may be necessary to define different vocabularies that resolve the ambiguity of a term in different contexts. It may be possible to use the same vocabularies if the term is always context-dependent, and the contexts (name spaces) are complementary.

[ejb] This is the general case: the business vocabulary was devised by the business people for business activities, and the models must refer to the business concepts. The vocabulary does not have to be “universal” in any sense; it's just that the vocabulary exists with or without the models that link to it.

[ejb] A detailed model may create new narrower concepts, and thus presumably produce a need to extend the business vocabulary. In practice, these refined things become new business acronyms, or terms prefixed with proper names for regulatory requirements, and the like. Whether the original business vocabulary is expanded, or a specialized vocabulary extends it, there is in every case an extended business vocabulary that supports the model concepts.

[ejb] It is not clear that every model element necessarily represents a “business concept”; some are truly artificial, or are glossed over in a general business category of things with technical differences uninteresting to business persons. So, linking a model to an existing business vocabulary may not result in linking every element, or in a one-to-one match on the meanings. It is also possible that the business term for a 'new' concept is in fact its “definition” – e.g., “a bank whose annual gross income is over 50 billion dollars”. That concept may not have an accepted business term, and thus would not normally appear in a vocabulary at all.

[ejb] No “namespaces” are involved in business terminology; 'namespace' is an IT concept. There are several different ideas in business glossaries: language, speech community, subject area, and context of use. An MVF 'vocabulary' is a “namespace” for MVF purposes. MVF takes the position that a “business vocabulary” is restricted to a language and a speech community (however broad) and may or may not select a single subject area. Subject area is a broad “context of use”, and may also appear as a qualifier on a term within a vocabulary for a wider overall audience. But the more common 'context of use' issues are verbs used with different types of subjects, and nouns denoting properties or actions of different subjects or used with different prepositions. E.g., transactions and companies may both have “buyers”, and companies might have buyers in both senses, like Whole Foods (but distinguished by a mergers/acquisitions subject area versus a retail operations subject area). So the term “buyer” may refer to different concepts in a retail vocabulary, but the ambiguity is resolved by 'context of use'.

Concept definitions might be expressed in a formal language that is vocabulary-independent. SBVR is a move in that direction. If definitions are expressed with concepts that can be expressed in multiple vocabularies, then a user could view a definition as expressed in a selected vocabulary (language). This would include not only referenced related concepts but also expression operators to define the relationships between the referenced concepts. This would then support search operations to find a concept of interest, and potentially logical operations involving the relationships between concepts in the associated user models.

If a user encounters a concept that is not defined in the imported vocabularies, or a term that is context-dependency that is not addressed, then the solution is as discussed in sub-case C, above, but the user may need to access special assistance for expression of the concept definition.

This would require a considerable investment and the work of specialists to develop the concept definition expressions. Most likely it would require associations motivated by business value to share the costs and returns on investment.

[ejb] I think this case (E) is the one case in which the idea 'context of use' is completely determined by the symbol-to-interpretation rules of the formal language. All modeling languages are formal languages, and so are OWL and CLIF and RuleML and RDF and … In formal languages there are symbol declarations and namespaces and other “module” concepts, and there may also be axioms and definitions. Appearances of symbols in those axioms and definitions and in other declarations are interpreted as references to other declared or built-in items according to the syntax and interpretation rules of the formal language. Whether such 'schemas' or 'modules' or 'ontologies' can or should be considered 'vocabularies' in the MVF sense is a separate issue.