MVF RFP Wiki

====== Differences ====== This shows you the differences between two versions of the page.

--- mvf:scenarios [2017/05/30 16:23]
ebarkmeyer_thematix.com [Formal language formulations in vocabularies]
+++ mvf:scenarios [2019/04/19 14:18]
admin [Formal language formulations in vocabularies]
@@ Line 7: / Line 7: @@
 The underlying idea is that there are two kinds of tools that support different aspects of MVF:
   * Vocabulary management tools provide for creating and editing vocabularies and vocabulary entries in various languages.
-  * Modeling tools provide for creating and editing models, and for linking the model elements to vocabulary entries. In their interactions with human users, these tools can present the model element documentation in the appropriate language, using the linked vocabulary entries.
+  * Modeling tools provide for creating and editing models, and for linking the model elements to vocabulary entries. In their interactions with human users, these tools can present and accept the model elements in the appropriate language, using the linked vocabulary entries.
 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.
@@ Line 56: / Line 56: @@
 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.
+[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.
 === A: Vocabulary for the active model ===
@@ Line 62: / Line 62: @@
 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.
+[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.
 === B: Vocabulary for a different model in the same language ===
@@ Line 70: / Line 70: @@
 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.
+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 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.
+[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.
 === C: Vocabulary not associated with a model supported by the tool ===
@@ Line 78: / Line 78: @@
 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:
+This is the general case -- the relationship of the vocabulary to other models is irrelevant to its import.
+[ejb] Some issues:
   - In general, the importing tool should be able to discard any part of the import that is not an MVF vocabulary, and that would imply that the exported vocabulary should be a separate, or separable, resource from any model per se.
   - The MVF view should be that the model is linked to the vocabulary, but the vocabulary, as exported, does not contain links to the model.  Importing the model imports the vocabulary (if the tool supports that), but not vice versa. So, what the imported vocabulary was for, other than the target speech community, is irrelevant to the import. Many models can link to the same vocabulary.
@@ Line 84: / Line 86: @@
-=== D: Universal vocabulary ===
+=== D: Universal vocabularies ===
 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.
@@ Line 105: / Line 107: @@
 ==== Discussion ====
-[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.
+[fac] This is Case E above, 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.
 ===== Scenario 6: Terminology for a metamodel =====
@@ Line 111: / Line 113: @@
 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.
+This Scenario requires the same MVF features as Scenario 3.
 ==== Discussion ====
@@ Line 127: / Line 129: @@
 ==== Discussion ====
 [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".
+[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".
 ===== Issues =====
-  - In general, the importing tool should be able to discard any part of the import that is not an MVF vocabulary, and that would imply that the exported vocabulary should be a separate, or separable, resource from any model per se.
+The following issues can be extracted from the above discussions.
-  - The MVF view should be that the model is linked to the vocabulary, but the vocabulary, as exported, does not contain links to the model.  Importing the model imports the vocabulary (if the tool supports that), but not vice versa. So, what the imported vocabulary was for, other than the target speech community, is irrelevant to the import. Many models can link to the same vocabulary.
-  - The user will be concerned with linking his model elements to the relevant entries in the imported vocabulary. The user may treat the imported vocabulary as an additional vocabulary to link his model elements to, integrate the imported vocabulary with his, extend the imported vocabulary per se, or adopt the imported vocabulary into his vocabulary, and use selected entries from it.  Those are all vocabulary management and linking functions.
-  - 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.
+==== Separable vocabularies ====
+In general, an importing tool should be able to discard any part of the import that is not an MVF vocabulary. That would imply that the exported vocabulary should be a separate, or separable, resource from any model per se. The vocabulary may be exported //with// the model, but it should not be //part of// the model.
+[fac] We should expect that each modeling language has a vocabulary that contains all of the terms that are used to describe its metamodel.  This vocabulary is the taken directly from the language specification and is used in the XMI for import/export of models in that language. Therefore, this is the same vocabulary (same terms and concepts) for all implementations of that modeling language.  This vocabulary may also include certain terms or phrases that express additional concepts that occur in standard displays.
+[fac] In addition, the implementation of a language will include display phrases and terms that are not included in the standard but are required for operational interactions with the user or are otherwise implementation-specific.  These should be specified in an implementation-specific vocabulary.  Both the concepts expressed by the language-specific vocabulary and the implementation-specific vocabulary should be expressed in vocabularies for expression in different languages.  Some (many?) of these concepts will be the same as those required by other modeling languages and could become consolidated in a library of vocabularies.
+[fac] But note that each modeling language should be first assumed to be a distinct context where many of the concepts are distinct even though they may be referenced using the same terms.
+==== Vocabularies are independent of models ====
+An MVF-enhanced model is linked to the vocabulary, but the vocabulary, as exported, does not contain links to the model.  Importing the model imports the vocabulary (if the tool supports that), but not vice versa. So, what the imported vocabulary was for, other than the target speech community, is irrelevant to the import. Many models can link to the same vocabulary; none of them owns it.
+=== Discussion ===
+[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.
+[ejb] I certainly don't want to assume that is the case. It is important that the business vocabularies are shared over interacting models for the same domains, because many of the same business concepts appear in different models.  (This is a fundamental presumption of the UML language family, but there is also a close tie between BPMN information artifacts and data models, and between agents and organization models.) And it is particularly true when there are multiple language expressions for the business concepts; you don't want different modelers translating a given English business term into different Japanese expressions.
+[ejb] I do agree that early use will probably just turn "comments" in the models into "definitions" in an attached vocabulary. But don't expect your modeling tool to be the choice for business vocabulary maintenance. There are lots of cheap (academic) tools that can export and import SKOS, and some of them have reasonable user interfaces.  And I have now seen at least 4 business vocabularies captured in ExCel (one of them was in three languages, but the definitions were all in English). And you can bet that major vendors in the enterprise modeling space will be providing their own integrated business vocabulary support.  The independent modeling tool vendor can get up-and-running on the target tool capabilities by importing their output, and later adding the vocabulary editing facilities to his tool UI.
+[fac] I think [ejb] assumes that we can quickly realize a universal set of business concepts so that when a user creates a model the challenge will be to find the existing concept (for which there are terms in multiple vocabularies.  I look at multiple modeling languages that appear to involve the same concepts but on close examination, the terms have distinct definitions.  I expect that users will continue to define new concepts because they may use the same terms in casual conversation, they actually are context-dependent concepts.
+==== Users control vocabulary relationships ====
+The user will be primarily concerned with linking his model elements to the relevant entries in //some// vocabulary. The user may treat an imported vocabulary as the reference vocabulary or as an additional vocabulary to link his model elements to, s/he may integrate the imported vocabulary with one s/he developed, extend the imported vocabulary per se, or adopt the imported vocabulary into his/her vocabulary, and use selected entries from it.  Those are all vocabulary management functions that may be associated with the linking process.  Dealing with multiple vocabulary integration is thus a major addition to modeling tools.
+[fac] IN general, where vocabularies are shared, individual (or group) users should not change the shared vocabulary as that could corrupt that vocabulary for other users.  Instead, if the vocabulary concepts are not precisely defined as needed by the user or the user prefers alternative terms, then the user should create a new vocabulary that inherits the concepts and terms of the shared vocabulary and overrides the share vocabulary concepts and terms for the user's model.
+[fac] The user might explicitly change the meaning of a term by linking it to a new concept definition so the shared concept has no term in the new vocabulary, or the user might define a new term for that concept.  Alternatively, the terms and usage for the shared an new concepts might be defined as relevant to different contexts.
+==== How are concepts linked across vocabularies? ====
+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.  In that case, the model element need only to point to one of them, and implicitly refer to the others transitively.
+[fac] Within a single modeling environment, or a single, shared vocabulary library, each concept must have a distinct element.  Similarly, each concept must have one definition, although that definition may be expressed differently in different vocabularies unless there is a formal expression language that enables the same definition to be expressed in the languages of different vocabularies.
+[fac] However, when vocabularies are shared, the user may need some of the same concepts and may have new concepts to add.  The fundamental problem is for the user to determine if there is a concept already defined or if a new concept is needed.  If the shared vocabularies include a vocabulary in a language familiar to the user then the search for a defined concept is easier, but candidate concepts may still not meet the user's requirement.  If there is no familiar-language vocabulary, then the user has a more difficult problem.  We might assume that there is an appropriate vocabulary for the modeling language, but the user will still need the help of somebody who can interpret definitions in one of the existing vocabularies..
+[fac] Note that a vocabulary library (a set of vocabularies) will have one concept element for each concept that is linked to the element for the associated term in each vocabulary.  Consequently, when a user wants to use and existing vocabulary library, either for a new model or to add vocabularies to an existing library, There is a need to support a mechanism for finding a concept if a needed concept exists in the library.  A couple approaches are possible: (1) provide a thesaurus to group similar concepts (requires the user to update the thesaurus when adding a concept), or (2) provide a taxonomy/classification network that traces general concepts to more specific concepts (easier for the user to update for new concepts).
+[fac] Defining a global identifier for each concept does not help since the user must still search for a desired concept and possibly refine an existing concept definition to distinguish a new concept.
 ==== Formal language formulations in vocabularies ====
@@ Line 148: / Line 186: @@
 [fac] 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.
 [ejb] MVF only needs to allow for this.  There is no reason why an OWL model or an OCL model cannot be viewed as a "vocabulary", in which the model elements are entries that have terms (model element names) and perhaps formulations in the language (in OWL EquivalentClasses or EquivalentProperties, in OCL def or inv).  In a similar way, an SBVR Structured English definition is a formulation in a formal language, not a natural language. In any formal language, as in any natural language, some terms are "primitive"; the modeler does not provide definitions.  So such "vocabularies" can be considered to be yet another representation of a concept set in some language, and model elements in models can be linked to them.  The only additional concern for these formal languages is the inclusion of "rules" or "axioms" that are not definitions, but are treated as part of the formal language "corpus".
+[fac] The use of a formal language would have a significant impact on the MVF metamodel: each concept would have a single definition.  The definition specified in a formal language could be expressed in a terms from a user's selected vocabulary.  This is quite different from the need to express each concept definition in multiple vocabularies, at least for alternative natural languages, but possibly the vernaculars/dialects of multiple communities.
+[fac] A formal language would also facilitate automated identification of equivalent or similar concept definitions.
+=== Mayo Clinic Examples and Potential Interface Discussion ===
+This presentation includes some thoughts by Mayo of how they would like to use the APIs produced by this specification. See {{ :mvf:mvf_discussion-mayo-20190419.pptx |}}
 [[http://www.omgwiki.org/mvf-rfp/doku.php?id=start|home]]

MVF RFP Wiki

User Tools

Site Tools

Page Tools