MVF RFP Wiki

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

--- mvf:issues [2017/06/12 17:10]
ebarkmeyer_thematix.com [Resolved Issues] added issues under Concepts, etc. and Vocabularies
+++ mvf:issues [2018/03/02 14:06] (current)
admin [Use of SKOS]
@@ Line 11: / Line 11: @@
 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).
+[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 things (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" ====
@@ Line 62: / Line 57: @@
 Does it affect the API?
+==== Support for Concept Search ====
+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.
+==== Primary/preferred term for a concept ====
+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)
+==== Vocabulary entries for verb concepts ====
+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.
+==== 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 ====
+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.

MVF RFP Wiki

User Tools

Site Tools

Page Tools