User Tools

Site Tools


This page is intended to summarize the modeling language requirements users and vendors have identified for SIMF at the CDM, LIM and MBR levels. These requirements are intended to be more detailed than use cases, enumerating modeling language features that may be needed. Note that this list is not intended to be complete as submitters to the RFP are expected to propose the modeling features required to fulfill the SIMF requirements. Summaries with references to additional detail is encouraged - please try and keep the descriptions in this document short.

Note: Below is a “starter set”, not intended to be complete.

Requirements for Federated Information Modeling

Conceptual Domain Model Requirements

The subject of the Conceptual Domain Model (CDM) is the domain, more precise the Universe of Discourse, hence the communication about the domain, not a certain information view (relational, object oriented, OWL, XSD) or computational structures. As such the CDM should specify terms, concepts, predicates, integrity rules and semantics of the domain in a way that makes sense to stakeholders. Likewise the CDM should avoid making “commitments” that are specific to a particular purpose or (software) technology but not required by the domain.


One of the most basic concepts of modeling, many logics and of most software languages is that of “types” and “instances”. The concept of types only makes sense in the presence of “instances” of those types. (We will discuss what we mean by instance, below; here follows an example of a type (predicate)with three variables: <Husband> married <Wife> at <InaugurationDate> is an example of a type; two associated instances are: Ronald married Jane on 1940-01-26 and Ronald married Nancy on 1952-03-04). However important types are, it is instances that are the reason for defining types. Communication at the instance level occurs is in business many, many times more than communication on instances. The consequence of type/instance that there is a need for an operator to add or delete an instance from the registration base of instances, in case the type is elementary; if the type is composite then an update oprator is also needed.

The concept of type in conceptual modeling is dynamic and multi-faceted to account for the fact that individuals may have many types, may be involved in many predicate (types)and these may come and go over time. For this reason types should provide for multiple classification and multiple inheritance. The concept of roles is also important and should have a direct representation and clear connection to other kinds of types.

The OO concept of a “Class” is generally considered to combine a type with a “factory” for instances of that type. Most OO languages do not allow for multiple classification, only some allow for multiple inheritance. UML allows for both.

Some modeling languages to not have a general or complete type/instance capability. See Also: Requirements for Federated Modeling

Reification Choices

There is a class of concepts that involve connections between entities (individuals, objects)where the concept can sometimes be defined as a relation and at other times defined as an entity class. When a relation is defined as a class it is called “reification”, objectification or nominalization. Reification is an option that typically is used when the relation needs to have some kind of identity supporting more than two roles, properties of the relation or tracking provenance of the relation; others prefer not to use reification.

In different models the same concepts will sometimes be specified using relations and sometimes be reified as types with a set of relations. While these two representations look very different they represent the same thing.

When using or extending an existing model it can be difficult if a relation has not been reified and you require some reification feature. Alternatively reified relations add complexity to what seems like it should be a simpler model. Since there is no direct way to connect the reified and non-reified relation semantically, separate models become disjoint where they should converge. SIMF will provide this facility.

Having two different ways to represent the same thing leads to complexity and stovepiping and should be reduced as much as possible. Our goal is to eliminate the need for the distinction at the conceptual level and to give the business modeler the option. Representation of Composite Concepts is one approach to eliminating the reification commitment. An example of this feature is: 15: The object type Marriage is the nominalization of the fact type There exists a marriage of <Person-1> and <Person-2> inaugurated on <InaugurationDate>. Here we see that the object type Marriage (class of individuals) is the nominalization of the predicate type with three variables.

See Also: Requirements for Federated Modeling

Multiple names for anything

Anything in any model should be able to be named by anyone, anywhere, in a federated modeling world. Names should be defined within context and users should be able to express the contexts that are relevant to their viewpoint, thus presenting information in their own terms. See Also: Requirements for Federated Modeling It may be useful in the SIMF community to use the following meta-predicate to precisely express this requirement as: <Element> in <Model> is referred to by <Participant> as <Name>.

Separation of naming from reference identifiers

A concept should be able to be described by multiple identifiers that provide access to descriptions of that concept and those reference identifiers should not be used as the names by which users see and understand concepts. Reference identifiers (i.e. a URI) should be hidden from users. This is required to maintain stability of concept references across multiple languages, communities, viewpoints and versions.


Context is essential in any conceptual understanding. The CDM should provide a direct representation of context. A concept, term, predicate, integrity rule and semantics should be able to be defined as contextualized by multiple context and the context relevant to a particular viewpoint should be defined in the users viewpoint. “Ownership” of a particular data element or description is one kind of context but should not overshadow other dimensions of context.

Representation of Composite Concepts

The representation of concepts should be sufficiently broad to encompass different viewpoints and use cases for the same concept. For example the concept of “marriage” and “spouse” are tightly tied, essentially the same concept look at in different ways. Likewise the “ends” of an association are different viewpoints on the same concept. When the relationships between these composite concepts are lost we have trouble understanding how they are related. See Composite Concepts for more detail.

No "dominant structure"

It is common to structure models into hierarchical packages that reflect the dominant decomposition of the system being modeled. The problem is that this dominant decomposition may be right for that one perspective but is not right for other uses, other views or other context that use the same information.

Even within one model it is often a poor choice to pick one decomposition – is it by the kind of element? By a functional decomposition or along project boundaries? Having to pick one organizational structure for model information is not acceptable; information should be able to be organized into multiple hierarchies or contextual dimensions as it is being defined and later when it is being used.

A more general concept of context is required, where something can be contextualized in many different ways. No one decomposition should be “primary” as primary is context dependent.

It is appropriate to have a dominant decomposition at the logical information modeling level.

See Also: Requirements for Federated Modeling

Patterns and Parameterization

At the conceptual level patterns are common and should be made explicit for reuse. Such patterns frequently require “parameters” when the pattern is used within a context. Capabilities for defining patterns with parameters and using those patterns within a context should be provided.

See Also: Requirements for Federated Modeling

General Constraints and Expressions

No language can cover all of the constraint requirements of all domains. A general expression based constraint capability, with the expression language well defined in the language, is required. Such expressions should be able to be parameterized so as to make potentially complex expressions reusable patterns in the conceptual model.

See Also: Requirements for Federated Modeling

Defining and Using Compositions

Representation of a composite along with its parts and the relationships between them is fundamental to architecture at all levels and domains, yet this basic pattern does not have a common representation. By defining a common set of composition concepts with well-defined semantics we can use it is a foundation for the many representations of composition in multiple languages and used in almost every model.

For this topic, please see the excellent article at the LIM level by Conrad Bock:

Units and Quantities

Languages designed for computation rather than conceptual purposes encourage or require the use of computational data types as the types of properties. Computational data types should be reserved for the physical representation. Conceptual modeling should deal with units, not data types, for the type of properties. The physical layer should then commit to data types for representation of these units.

See: SysML and ISO 80000

Open Definitions (aka Open World Assumption)

In most computational languages, including “OO” modeling, the definition of some concept is made in one place and can’t be extended or modified. In most logical languages definitions can be extended in other context. One expression of this is the semantic web notation that “anyone can say anything about anything, anywhere”. In a conceptual modeling environment this kind of open definition is required. For example, you may want to add a supertype to existing types to describe some features in common. This is related to the “open world assumption” (OWA), but OWA carries with it some logical consequences that are not always desirable, such as the inability to represent defaults.

General Modeling Capabilities

The modeling capabilities, above, are those found mission from many information modeling capabilities. It is assumed that “normal” modeling capabilities are included. However some modeling languages lack some of these normal features. For example first order logic (FOL) languages frequently lack the ability to represent defaults or relations to classes as these are difficult to reason over with some logics. Both of these capabilities are required for conceptual modeling. For example it is normal for a business model to have conditions ranging over types, constraints and processes, which is not supported in FOL. There are some extensions to some FOL languages that allow for these capabilities.

Logical Information Model Requirements

The subject of the Logical Information Model (LIM) is the representation of information about the domain. i.e. “records” and data structures. The LIM should utilize CDM concepts but make additional commitments that are appropriate for defining information required for a particular use. However, the LIM is intended to be “technology independent”, that is the same information structures should be able to be implemented using a variety of technologies in the Physical Domain Schema (PDS).

Note that there may by multiple records or data structures about the same thing and that the structure and identity of a record is not the same as the identity or structure of the thing it describes.

Reuse of concepts and terms from the conceptual model

Current modeling practice requires users to type in new names for almost everything. A logical modeling capability supported by a CDM should encourage use of existing terms and concepts - perhaps “drag and drop” of concepts from the conceptual model into or onto logical models. With appropriate semantic precision the names for logical elements can then be derived from the conceptual level. Of course the ability to provide a distinct “tag name” for a logical element must still be supported, particularly for the use case of federating existing logical and physical models.

Separating what can be known from what may be or must be known

In the conceptual model we want to capture concepts that may be used in multiple information context. In a specific information model for a specific purpose we should specify what elements are required or optional. For example, we may understand a lot of concepts that can describe a person such as: weight, height, spouse, income, employer, address, etc. For a particular record we may only be interested in name and address but may allow weight and height as optional. So in the context of a “person record” we want to “commit” to what is required or optional.

Understanding the difference between concepts we know and what may be required or optional for a particular purpose or in a particular record is a fundamental separation of concerns that allows us to connect different representations through common concepts.

Allowing for inconsistency and differing opinions

Models contain assertions about things that may or may not be true or consistent with other assertions others may have made about the same things. In fact, one important use case of information federation is understanding where different information sources differ. Each record about something is an assertion, how much someone else trusts that record of that assertion is up to them. At the logical information modeling level SIMF should allow for differing opinions (inconsistencies) about the same thing. Even if something has a single value conceptually, there may be multiple values in various information sources.

Specifying Structure

While at the conceptual level we want a more “flat” treatment of concepts and to allow for various hierarchies, in a particular logical information model we may want to commit to a given structure and dominant decomposition. The logical information model should be able to specify such structure for information records based on conceptual constructs. The logical information model should present information in ways that make sense for particular stakeholders with a particular purpose.

Specifying Representation of Composite Concepts

While at the conceptual level you what to understand composite concepts and their relationships to various verb phrases, at the logical level the modeler may want more specific structures and properties. In many cases composite concepts are “flattened” to one or a small number of properties. The logical model needs to be able to represent these flattened structures and the model bridging relations need to be able to show how these different representations are connected.

Closing Definitions (aka Closed World Assumption)

While in a conceptual model open definitions are desirable, specific requirements and computational systems require fixed definitions – as do languages such as Java. Java would not take kindly to a superclass being added on the fly! Therefor it is required that definitions are able to be closed in a logical information model. If there is also an “open world assumption” then this will likewise “close the world”. Closing definitions is just another kind of assertion to be made about a logical model. Definitions can be closed in a given context while being open in others.

Views and viewpoints

What is a viewpoint? A viewpoint specifies a reusable set of criteria for construction and selection of model elements, addressing particular stakeholder concerns. A viewpoint may be partially expressed through the meta model elements that it exposes, but may also include less structured expressions. A view is a representation of part of a system that conforms to a viewpoint.

Viewpoints define a particular perspective for users and the purpose, structure and constraints relative to that perspective. These are used to subset and present the model for users interested in that viewpoint.

Model Bridging Relations Requirements

section -to do-

Semantic Metadata—Tapping the Potential of Semantic Ontologies

See the article entitled Semantic Metadata—Tapping the Potential of Semantic Ontologies“ in David Frankel's MDA Journal, a quarterly feature of the online journal Businss Process Trends. Go to, which lists the MDA Journal articles in reverse chronological order and look for the article, which was published in February 2010. This is the kind of capability that could be part of MBRs. A standards organization for the banking industry named Banking Industry Architecture Network (BIAN) has defined a metamodel based on these concepts and extrapolated for service-oriented architectures, and will soon be defining corresponding content. For more information on BIAN, see the MDA Journal article on the subject published in June 2011, which is not a technical article but sets the background of BIAN's motivation for using semantic technology.


Projection provides for the calculating of one view of a model from another. A well known projection capability is “views” in SQL where a virtual table is created by a query on other tables. Projection is one way to express how patterns of concepts can be represented (projected) in a logical or even physical information form. Projection uses rules to connect patterns of the “source” to patterns of the projected information.


A particular information structure has a purpose. Represention purpose provides a way to connect a logical model to a conceptual model. But what is purpose and how can we represent it?

Purpose of a record

If we accept that the information model defined records about something then there are a limited number of purposes to such records. Examples include typical “CRUD” use cases:

  • Creating a new record of something, probably with relationships to other things that exist.
  • Establishing a link to something that exists, probably as part of a create or edit.
  • Removing a record, link or property.
  • Editing or otherwise changing properties or relations of something.
  • Returning a copy of information about something.
  • Specifying a query of something.
Purpose of a property or association

Such information records tend to have properties and relations, each of these also has a purpose:

  • A “snapshot in time” of some value: something asserted or assumed to be true (the common case of an attribute with no indication of why the attribute is as it is)
  • A measurement at a point in time
  • An expected or desired value
  • A value prescribed by policy
  • Any of the above as a single value or time series

Identifying the purpose of an information element along with its domain concept provides a reasonably complete representation of its full semantics.

Example - Sue's Weight

Simple Bridging Relations

Languages such as SKOS and OWL provide simple bridging relations such as:

  • “same as” – the subject elements represent exactly the same concept
  • “equivalence” – the subject elements are representations of the same domain thing or set of things but may have different ways to model those things
  • “disjoint” – the domain things represented by the elements are different, the intersection of their extents (populations) must be empty
  • “narrower than” – a concept that is a more specific variant of another
  • “broader than” – a concept that is more broadly defined than another
  • “subset” – a set, whose populations is part of another set
  • “superset” – a set, whose population includes another set
  • “union” – the union of the members of two or more other sets
  • “intersection” – the intersection of the members of two or more other sets


Dr. Peter Bollen , 2011/07/31 15:13

In the paragraph: 'Separation of naming from reference identifiers'

I would propose to replace (line 1): 'A concept should be able to be described..” by 'A concept should be able to be identified..” and to replace (line 2):'…reference identifiers should not be used..' by '…reference identifiers should not necessarily be used..'

In the pargraph: General Modeling Capabilities I would propose to replace (line 1): 'The modeling capabilities, above, are those found mission from .. ' by 'The modeling capabilities, above, are those found missing from… '

simf_required_modeling_capabilities.txt · Last modified: 2011/07/29 15:01 by sjirnijssen