This page captures the issues that have undergone, or are undergoing, significant discussion among the participants to the joint submission.
These issues have not been resolved by any clear agreement.
Do we really mean “representation of ‘concept’” or specification of the concept: Concept?
[odell] we need a ground notion of Concept, while also providing for different “views” or “perspectives” of an instance of Concept, such as: multiple terms for a specific concept, multiple intensions for the same term (which is really multiple concepts with the same label).
We also need to consider co-extensive concepts (e,g, Morning Star, Evening Star) that are specified using different characteristics but refer to the same set of things–over all time–(of the business).
[fac] Many “concepts” in our business discussions and models are not distinct concepts but are terms that have slightly different meanings in different contexts or are simply ambiguous. When we consider the number of distinct concepts that must be defined for all these variations, I believe there will be thousands of concepts to be represented. We cannot simply offer users these thousands of concepts to select for their models, but we must provide a way that they can find a specific concept or determine that it is not yet represented so they can create what they need. This requires a structure and search mechanism to expose relevant candidates and possibly help the user understand the distinctions between them.
[fac] This is a problem for a user attempting to use an existing vocabulary library (a set of concepts with a set of associated vocabularies where not all concepts may be expressed in all of the vocabularies). It is a problem for consolidating vocabulary libraries. The problem is more difficult if the user is not familiar with a language that is used in a vocabulary that covers most of the concepts. The problem is less severe when the scope of sharing is for models in a particular modeling language because the modeling language implicitly provides a structure that “hosts” the concepts.
[fac] A traditional search facility is a thesaurus. Another approach might be a taxonomy (or lattice?) that allows general concepts to be traced to more specific concepts. A formal definition language would help if the definition language is expressed in terms of defined concepts and can be exposed in a selected vocabulary–this would facilitate an automated search. But this requires a substantial body of concepts and at least one vocabulary that covers most of the concepts so that humans can understand the definitions. But the business value of MVF requires multiple vocabularies (at least multiple natural languages).
What exactly does a model element link to? A concept? a vocabulary entry? Something else?
We agreed that a model element links to an object temporarily called an MVF Entry. What an MVF Entry actually is is discussed in detail on the MVF Entry page.
A vocabulary is a collection of terms related to concepts represented by definitions or descriptions (a weaker notion). What is the conceptual organization? What is the nature of a vocabulary entry? What is the relationship of a “concept” to a vocabulary “entry”?
The list/set of concept entries expands to a set of terms that point back to the concept, and the terms are sorted or hashed to enable looking up concepts using the terms.
Multiple entries in different vocabularies then represent the same concept, but each has its own IRI. How are they linked? Is there some common IRI and if so, how does it get created?
The definitions/descriptions must have IRIs that extend the vocabulary IRI. Again, the same concept will have different definitions in different vocabularies/languages and thus different IRIs. How are they linked?
So what has the IRI? The term-in-context? Or the “designation” relationship? Or the definition/description?
How are designations linked across language vocabularies? And does the model element link to a designation?
Real glossaries often contain other elements in entries, such as notes, examples, other forms/spellings, pronunciation guides, synonyms (with or without differentiation), antonyms, etymological information, etc. MVF should certainly allow the managed vocabulary resources to have this stuff.
Do we need to model this at all?
Does it affect the presentations in modeling tools?
Does it affect the API?
How does the multiple vocabulary and entry/concept model support search? When the user wants to find out whether a term is already present, that's easy, but what if s/he has a definition in mind? How does he find terms that have that meaning, or something like it?
We should support SKOS broader/narrower, aka ISO 1087 subordinate/superordinate, OWL/UML subclass/“superclass”).
[Ed] We need to support X.broader in vocabulary entries, because it is part of the nature of the concept. But it is not clear that supporting the list of X.narrower concepts is a good idea. It is hard to be sure it is complete, and it creates problems if X is adopted into the vocabulary that defines the narrower concept. Of course, if the relationship is stored as a separate relational table, you get both directions automatically.
[Pete] Looking at subtypes of a more general class is a common way to search for a narrower concept. We should support that, even if the tool has to do it by brute force search. These vocabularies will not be huge data sets.
Should there be a primary/preferred term for each concept, in any given vocabulary?
Should it just be possible to declare one, but not required?
Can the user choose the term s/he prefers to see? (As distinct from the primary term being stored in the vocabulary and thus standardized for all users)
It should be possible to associate properties or relationships (not just classes) with business terms.
Does an MVF vocabulary have to support verb entries?
[Ed] Dictionaries treat verbs as transitive or intransitive, but a lot of them have different meanings when associated with different subjects or adverbial phrases. That is why SBVR introduced “verb concept wording”, which is not ISO 1087, but is typical of modeling languages.
[Pete] Properties are relationships, and relationships can be expressed by noun terms in business vocabularies.
[?] Some modeling languages model actions and processes as well.
A single term can have multiple meanings even in the same speech community, depending on the context of use. This issue is discussed on the context-dependent terms page.
Do we want to specify SKOS as the basic vocabulary model? Or do we specify our own vocabulary model and a mapping to/from SKOS?
Does SKOS have everything we need?
SKOS supports multiple languages by adding RDF entries using rdf:about for existing entry and adding entries with different language markers.
Do we need all of SKOS? Should we be specifying only a required subset?
[Pete] We should minimize requirements for basic MVF vocabulary support, so as to encourage implementation.
[Ed] Agreed. We want a really basic capability, but upward compatible with whatever extension some vendors might want (and already implement). We just have to be sure that the basic set is, in fact, upward compatible with a richer capability.
[Elisa] Thematix wants to add support for a much richer subset of ISO 1087-1, because we have found it useful in dealing with the conflicts and nuances in the finance industry. So we would want to specify that model, which goes well beyond SKOS, but MVF should treat most of it as an optional extension to the basic support model.
[Elisa] In addition to SKOS, we should review the lemon and babelnet ontologies for their approach to representation of multilingual synsets, and potentially map MVF to those ontologies after integrating any relevant concepts or properties that we don't already have. See http://www.lemon-model.net/lemon# for the Lemon ontology and http://babelnet.org/model/babelnet# for the babelnet vocabulary.
There appears to be joint agreement on the resolution of these issues, although they may give rise to others.
These elements are taken primarily from ISO 1087.