mvf:term-in-context
====== Differences ====== This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
mvf:term-in-context [2017/06/19 18:22] ebarkmeyer_thematix.com created from Fred's text |
mvf:term-in-context [2017/06/19 18:36] (current) ebarkmeyer_thematix.com Annotated E |
||
|---|---|---|---|
| Line 21: | Line 21: | ||
| 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. | 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. | ||
| ===== C: Vocabulary not associated with a model supported by the tool ===== | ===== C: Vocabulary not associated with a model supported by the tool ===== | ||
| Line 32: | Line 33: | ||
| 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. | 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. | ||
| ===== D: Universal [set of] vocabularies ===== | ===== D: Universal [set of] vocabularies ===== | ||
| Line 40: | Line 42: | ||
| 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. | 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'. | ||
| Line 51: | Line 61: | ||
| 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. | 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. | ||
mvf/term-in-context.1497910963.txt.gz ยท Last modified: 2017/06/19 18:22 by ebarkmeyer_thematix.com
Page Tools
