mvf:issues
====== Differences ====== This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
mvf:issues [2017/06/12 21:02] email_jamesodell.com [Representation of Concept] |
mvf:issues [2018/03/02 14:06] (current) admin [Use of SKOS] |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| 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). | 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). | ||
| - | ==== Linking model elements to concepts ==== | ||
| - | What does a model element link to? Some "concept" object? Multiple terms/entries in different vocabularies? | + | [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. |
| - | * Proposal: Placeholder ‘concept’ object lives somewhere. It is linked to entries in multiple vocabularies. Model elements link to it. | + | [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. |
| - | Where does it live? Is it in a separate resource from all vocabularies? | + | [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). |
| - | + | ||
| - | Is it just an IRI that all the related language vocabularies agree to use? | + | |
| - | If so, then the link from the model element is the IRI, but how does the modeling tool find the language-based vocabulary entries? | + | |
| - | * Proposal: The model element contains the links to all of the corresponding vocabulary entries. The idea that they represent the same concept is implied. Effectively, the model element is the cluster point and the reference form of the concept. | ||
| - | Objection (Evan): The business concept exists without the model. The model element should not be the center concept. Model element to concept relationships are also many-to-many. Different models may have links to different vocabulary entries (in different languages) for the same concept. How would the modeling tool or the user find translations of a business term that are only linked by other models? | + | ==== What a model element links to -- the "MVF Entry" ==== |
| - | * Proposal: A concept is a vocabulary entry, or something in a vocabulary that entries link to. These entries can be linked to each other across vocabularies, or in a separate resource (a la Linked Open Data). The model element can point to any of those resources as a starting point. | + | What exactly does a model element link to? A concept? a vocabulary entry? Something else? |
| - | The effect is that the model element points to one element of some kind of linked list. How does one add to the list? Is it circular? And how easy is that to maintain, if multiple tools are involved? | + | 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:MVFentry|MVF Entry page]]. |
| ==== Nature of a vocabulary "entry" ==== | ==== Nature of a vocabulary "entry" ==== | ||
| Line 93: | Line 88: | ||
| [?] Some modeling languages model actions and processes as well. | [?] Some modeling languages model actions and processes as well. | ||
| + | ==== Context-dependent terms ==== | ||
| + | |||
| + | 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 [[mvf:term-in-context|context-dependent terms page]]. | ||
| ==== Use of SKOS ==== | ==== Use of SKOS ==== | ||
| Line 109: | Line 107: | ||
| [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] 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. | ||
mvf/issues.1497315771.txt.gz · Last modified: 2017/06/12 21:02 by email_jamesodell.com
Page Tools
