MVF RFP Wiki

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

--- mvf:required_features [2017/07/24 16:19]
fred.a.cummins_gmail.com
+++ mvf:required_features [2017/08/03 10:22] (current)
fred.a.cummins_gmail.com
@@ Line 1: / Line 1: @@
-====== Features of the MVF Specification ======
+===== Features of the MVF Specification ======
 The "major features" are extracted from the usage scenarios.  The detailed features are extracted from the RFP.
@@ Line 155: / Line 187: @@
 ====== 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.
+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.
 .	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 delegate to another vocabulary to specify terms such that a new vocabulary may specialize terms for certain concepts and add terms for additional concepts thus reducing the work required to define a vocabulary for another community of discourse.
+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.
-c.	A vocabulary will specify the community of discourse for which the vocabulary is intended.
+**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.
-d.	A vocabulary will specify a natural language that is the basis for the terms/designations specified by the vocabulary.
+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.
 .	Vocabulary package/library. One or more vocabularies may be managed as a package or library of vocabularies to exchange and maintain together.
-a.	Concepts are not duplicated within a package/library or in a modeling environment.
+**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.
-b.	a package/library or selected vocabularies can be imported/exported as XMI.
+a.	A concept has only one representation within a package/library or in an operational, MVF-supported modeling environment.
-c.	A modeling tool may have a complementary library for the metamodel and other tool-specific concepts.
+**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).
-d.	A separate vocabulary package/library may be defined for the terms/designations required for a modeling language.
+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).
-.	Terms/designations.  Terms/designations are character strings associated with a vocabulary to express modeling concepts in inputs and outputs for a modeling language and user model(s).
+**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.
+.	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.
+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.
-	Business terms.  Support for “business terms” reflects common terminology that may not reflect precise definitions of modeling concepts.
+.	Business vocabulary.  A vocabulary of generally accepted business terms.
-a.	A vocabulary of relevant business terms can be defined as a basic set of terms to be complemented and specialized with more specific vocabularies.
+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.	A vocabulary of generally accepted “business terms” is defined as a basis for a modeling vocabulary that qualifies (adds qualifiers) to the business terms to resolve ambiguities and improve specificity for expression of model concepts.
+b.	Business vocabularies should come with standard concept identifiers.
-.	Synonyms.  Users can use and view terms that are familiar and meaningful to them but may not be desired terms of other users that share the same spoken, natural language.
+.	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.
+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 can be defined in a specialized vocabulary for another community and default to remaining terms specified by the primary vocabulary.
+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.
-.	Concept.  A concept represents the meaning of an element of a modeling language metamodel and/or user model(s) element.  A concept is translated to An appropriate term for a concept is selected from the concept entry of a user-designated vocabulary.
+.	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.
+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.
@@ Line 213: / Line 286: @@
 e.	Concept identifiers for a modeling language metamodel are defined for the modeling language specification,
-f.	MVF applies to instances of user model elements
+f.	MVF applies to representations (examples) of instances of user model elements
-g.	MVF applies to modeling language extensions (Ref: BPMN, UML profiles?)
+.	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.
-.	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.
@@ Line 227: / Line 298: @@
 d.	Concept reference links may provide access to external definitions of the concept.
-.	Taxonomy/thesaurus. A taxonomy of concepts could help a user find the appropriate designation of a concept.  A directory of similar concepts (thesaurus?) could also help a user find the term for a specific concept.  Either of these techniques would be enhanced by access to concept definitions in the appropriate natural language.
+.	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.
-.	Name space.  A name space identifies terms that that have a distinct concept/meaning within the scope of a containing model element.
+a.	. Support for a taxonomy of concepts could help a user find the appropriate designation of a concept.
-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.	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,
+.	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.
@@ Line 237: / Line 315: @@
 c.	What determines the depth of scope of a name space?
-.	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.
+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.
+.	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.

MVF RFP Wiki

User Tools

Site Tools

Page Tools