Semantic Concept Modeling UML Profile

Transcription

1 Semantic Concept Modeling UML Profile 1 Semantic Concept Modeling UML Profile Semantic Concept Modeling Introduction What is a semantic concept model? Semantic Domain Models as Reference Models Advantages of semantic concept models Federation Data & Application Governance Inference, Machine Learning and Rule Processing Forward Engineering Thinking Semantically Expressing Semantic Models in UML What semantic models don t assume Semantic Models and Ontology Languages Many Kinds of Logics Requirements for Semantic Model Logic Essential Semantic Model Extending the essential model Packages Representing Subject Areas Classes representing Domain Entities Instances Class Generalization UML Associations Representing Domain Relationships UML Aggregation Kind Association Classes as First Class Relationships Attribute Properties Roles Context of roles and with respect to Phases P a g e S e m a n t i c M o d e l i n g P r o f i l e

2 Categories Example Essential Model Enhanced Semantic Model Precision Class Hierarchy Semantics Overlapping and Incomplete Subclasses Disjoint and Incomplete Subclasses Complete and Overlapping Subclasses Disjoint and Complete Subclasses Kinds of classes Anything Union Intersection Quantity Kinds and Unit Types Enumerations Equivalent Class Property Semantics Subject (domain) and type (range) of an attribute Cardinality Property Hierarchies Property Restrictions Inferring a type from its properties UML {id} Property Chain Equivalent Property Enumerates Transitive Property Symmetric Property Synonym Annotation UML Constraints Other Stereotypes Same As External Reference Resource <<Represents>> {TODO} P a g e S e m a n t i c M o d e l i n g P r o f i l e

3 1.5 Kinds of Models UML Features with no Semantic Model Interpretation Semantic Concept Modeling Profile (SCMP) Reference Semantic Concept Modeling Profile (SCMP) Diagram Stereotypes Stereotypes Properties P a g e S e m a n t i c M o d e l i n g P r o f i l e

4 1 Semantic Concept Modeling UML Profile This section defines the UML profile for Semantic Concept Modeling (SCMP). In order to improve UML s suitability for modeling real-world concepts, this profile interprets standard UML with semantic extensions, as detailed below. The SCMP is part of an in-progress standards effort within the OMG, it is provided here as an open sourced resource under the LGPL License 1. The SCMP is an implementation of the in-progress Semantic Information Modeling for Federation process within the Object Management Group. 1.1 Semantic Concept Modeling Introduction What is a semantic concept model? A semantic concept model is a model of concepts about a subject area, as understood by a community of stakeholders, defined in such a way that the meaning of those concepts can be precise, understood by the stakeholders and processed by computer software. Other kinds of semantic models can include capabilities, processes and services, our focus here is the concepts within a domain or topic area. This document introduces a particular formalism and language for semantic concept models. Semantic concept models (We will just call these semantic models ) are structured information about the subject area, as opposed to unstructured information, such as natural language. The concepts, terms and structure used to define a semantic model is a language for Semantic Modeling. Expressing a model in a Semantic Modeling language helps to define the meaning of the concepts in that model, the model semantics. Each concept in a model becomes the definition of a term in the domain vocabulary, linking how stakeholders speak about their domain and how it may be expressed in a systems. While a Semantic Modeling language provides a foundation for defining the semantics of concepts, it is not enough. The language must be used with care and precision to capture, disambiguate and precisely define the concepts. We also need a library of starter concepts so that every semantic model doesn t have to start with a blank page. 1 LGPL: 4 P a g e S e m a n t i c M o d e l i n g P r o f i l e

5 There are multiple terms that, more or less, capture some of the intent of semantic models. Some of these terms include: Semantic model Concept model Ontology Conceptual Domain Model Computation Independent Model (CIM) Conceptual Information Model Structured Taxonomy Business Information Model (BIM) Semantic Domain Models as Reference Models Anything can be modeled semantically. The focus of the Semantic Modeling UML profile is to capture the semantics of domain concepts. Domain concepts are the actual things we deal with in our business, mission or life such as: people, places, things, agreements, and situations. Semantic domain models may look somewhat like data models or object-oriented programming models, but these are models of technology solutions not the domain. When we attempt to mix the model of a domain with a solution architecture both tend to get distorted. We create the Semantic Concept Model as a reference for what design models mean and the real-world things they represent and impact. From this point forward we will consider Semantic Model and Semantic Domain Reference Model to be synonymous. 5 P a g e S e m a n t i c M o d e l i n g P r o f i l e

6 For the above reason, the Semantic Concept Model is considered a reference model not a solution design or data model. It is referenced by multiple designs to help define and federate them. This is particularly important for data models; while a Semantic Concept Model may look somewhat like a data model, the concerns should not be mixed the domain model is a model of domain concepts, not how those concepts are represented in data schema or object-oriented programs. Figure 1 Data Represents Concepts The pattern of data represents concept is essential to leveraging semantic models. This pattern frees implementations from slavish compliance with a structured enterprise data model while connecting data to its meaning in the semantic model. 6 P a g e S e m a n t i c M o d e l i n g P r o f i l e

7 1.1.3 Advantages of semantic concept models A semantic model defined by subject matter experts is more durable than a data model or logical information model designed with a particular system in mind. Thus, one definition of concepts and properties can be represented by multiple logical models, each optimizing for different technical goals. Note that there are multiple interpretations of logical model that span from conceptual to near a data schema. Semantic models can be used to help federate any of these levels of abstraction. Figure 2 Leveraging Semantic Models The key use cases for semantic models fall into the following categories: Federation Systems have been designed to solve specific problems for specific organizations or stakeholders. Requirements for these systems and the technologies they are implemented in drive data models, services models, component boundaries, algorithms, security concerns and other design related viewpoints. The process of collecting requirements and producing bespoke designs has been proven to create reliable operational systems. As computing has evolved we have moved from the era of independent systems to systems of systems. Systems no longer stand-alone but are part of a vast network of interconnected systems that power our enterprises and society. These systems of systems must operate in a coordinated way and, within an enterprise, be managed to reliably enable our enterprise processes. But, since each such system is independently designed they don t naturally work together new integration systems are designed to connect the dots, the network of systems and integrations becomes complex and very difficult to manage or change. There is no visibility of how the system of system fits together or works as a whole. The Semantic Concept Model becomes a reference point for the system of systems, by capturing the domain (business) concepts that all these systems operation on, it becomes a pivot point between the different ways different data structures represent the same concepts about the same domain. This pivot point can be used by people or systems for federation, federation provides for: 7 P a g e S e m a n t i c M o d e l i n g P r o f i l e

8 Federated Analytics capturing data from within and outside the enterprise to derive new knowledge, including data science and machine learning. Enterprise Knowledge Graph an EKG integrates and federates data from multiple sources inside and outside of an enterprise to provide a unified and consistent view of information that can be queried, transformed and analyzed as a single (virtual) dataset. EKGs are typically implemented using the Semantic Web 2 technologies. Collaboration and Information Sharing working between different business units, enterprises and systems in an efficiently and collaboratively. Data & Systems Integration Connecting the dots between all the systems and data that must be integrated Data & Application Governance Due to the natural proliferation of overlapping and related systems, the same business concept can be represented in multiple systems, databases, messages and applications. Most of these systems probably have a different representation, term or schema for these same concepts as discussed above in system of systems. Where metrics are produced from source facts, they are often derived from these system and technology artifacts in ways that are inscrutable for business stakeholders (and sometimes even for the technologist!). Policies about data, such as what is sensitive or personally identifiable is difficult and expensive to comply with since there is no one place to make a policy about what the data represents (such as a SSN), but only how it appears in dozens of systems. A semantic model defines what data means, not how it is represented. Implementation schema and/or data models can reference semantic models for their meaning. This provides advantages for both sides; an element in a data schema can be traced back to its semantics to find the policies and business stewards applicable to that concept. A business concept can be traced back to the data elements that represent it along with identification of systems of record, systems of reference and the lineage of how business facts travel though the system. The use cases for leveraging semantics for governance include: Grounding the meaning of data in a simpler, more business focused semantic model. Applying business rules to business concepts which can then flow through to data assets. Separation of the business governance of information from the technical governance of data assets and applications Understanding where business facts are stored or transmitted and which are authoritative Understanding the lineage of business information through the system of systems Inference, Machine Learning and Rule Processing Once information is semantically well defined and federated it can be processed algorithmically to derive new knowledge and insight. There are multiple approaches and technologies to leveraging information, but they all depend on the semantics of the information. Some of these approaches and technologies include: Application code application code can be written, and sometimes generated, to leverage the semantic model for more intelligent data. Rule based systems business and operational rules operate on domain concepts to enforce policy, validate compliance and deduce new information. 2 Semantic Web: 8 P a g e S e m a n t i c M o d e l i n g P r o f i l e

9 Inference engines semantic models mapped to logic based languages, such as the Ontology Definition Language: (OWL), ERGO, and Common Logic (CL) can infer new information from existing data. Machine Learning Machine learning depends on well defined (semantic) data to define and discover patterns in data Forward Engineering Forward engineering is the process of taking a more general model, such as a semantic reference model, adding design choices, and then producing a design that is consistent with both the reference semantics and the business and technology choices. Forward engineering can be manual or automated. When designs are forward engineered from semantic models they are more grounded in business concerns, easier to maintain and more naturally able to integrate and federate. Forward engineering is particularly effective in producing: Data models Message models for services and API architectures Implementation of business rules Domain Driven Design 3 models Thinking Semantically A semantic model is not an information or data model. When someone thinks about concepts, they think about real-world things, not data structures or even natural language text about those things. These real-world concepts become the pivot points around which we define and relate the many terms, languages and data structures that describe those things. For example, every Person has biological mother one other Person, which is essential to being a Person. Such concepts provide criteria that narrow the definition of what a Person concept is, it does not specify that a system should store every person s mother. For another example, it would be reasonable for a semantic model to assert that an eye has a measurable visual acuity, but not to define how visual acuity will be represented within a computer as bits and bytes, or how often visual acuity will be stored within a database. Such technical concerns should be elaborated in a data model, which has elements that can become well defined by referencing a semantic model. Note, however, that things such as DBMS-tables and columns are valid concepts in their own right as data things, but they are different from the real-world concepts they might represent. Semantic models can be modular. A semantic model may refer to things in a number of other semantic models. This is useful for refining another organization's semantic model, separately maintaining overlapping concepts between organizations or disciplines, or more easily managing smaller subject areas. A semantic model consists of a network of concepts with a simple essential structure. That structure is the definition of classes, relations between them and their characteristics. Classes represent abstractions of things in our world including physical things like trees or people and made up things like agreements. Other concepts connect things - the relations between things are represented as UML associations that can have attributes. Things have attributes (characteristics) such as weight or color. This basic network of classes, associations, and properties forms the foundation of the semantic model and defines the conceptual framework and vocabulary of a domain. Each of these concepts may have names, which form the vocabulary of a domain of interest. Various assertions are then made about these concepts and their connections that further refine the 3 Domain Driven Design: 9 P a g e S e m a n t i c M o d e l i n g P r o f i l e

10 semantics of those concepts multiplicities of relationships, specializations between concepts, essential properties of things, etc. One of the fundamental ways we understand and organize concepts is their arrangement into hierarchies, where general concepts are specialized to form more specific concepts within a specific context or with more specific characteristics. A semantic model can arrange all the fundamental elements into conceptual hierarchies using generalization relationships. In contrast, another kind of hierarchy is a structural data hierarchy where data elements contain other data elements. As the purpose of a semantic model is not representing data, data hierarchies are not part of a semantic model, they are typically part of logical information models that represent concepts. To allow for the many viewpoints that can exist for any concept, a concept can be in many generalization hierarchies at the same time Expressing Semantic Models in UML A semantic model can be expressed in many ways, this profile uses UML with the Semantic Concept Modeling profile. UML, with a few enhancements, makes an effective Semantic Modeling environment supported by standards and multiple tools. UML is understood by most architects and is already a part of the toolbox in most enterprises. While UML has typically been used for system design, it has proven very effective for Semantic Modeling. Also, by having semantic models in UML they can be more easily connected with design models for federation, inference and forward engineering. The capability of UML to have multiple diagrams, dictionaries or other ways to express the same model for different stakeholder viewpoints is particularly effective. While we typically start with class diagrams, such diagrams are only one way to view a model. The Semantic Concept Modeling profile defines the interpretation of UML concepts used, extends UML concepts with stereotypes and makes some UML semantics more specific to Semantic Modeling. The formal semantics of the foundation of UML may be found in the Foundational UML specification. While there are some extensions, every effort is made to use generic UML class diagrams, as they are well understood and supported. SCMP only provides stereotypes to extend UML to make semantic models more expressive. For example Roles and Phases are defined to describe how entities may be classified in different context or over time. These extended notions are introduced here, in subsequent sections. Readers are referred to the UML specification and the many books and courses on UML for an in-depth treatment of generic UML. The subset of UML used for Semantic Concept Modeling is primarily that known as Class models, the most commonly used part of UML. Our scope further narrows what we utilize to exclude behaviors and methods elements used for object-oriented design. Those elements may be present, but they are ignored for the purposes of Semantic Modeling. Logical design models expressed in UML can be related to their meaning in a semantic model. SCMP provides specific capabilities to enable these connections. Expressing semantic models in UML is not a dead-end or paper architecture, the semantic model expressed in the SCMP can be combined with business or technical choices and transformed to a variety of technologies, these include: Web Ontology Language (OWL) ERGO Logic Entity/Relational models Schema for SQL, XML, Jason, and other data technologies Some tools also provide reverse engineering and/or round trip capabilities to import existing ontologies into UML based semantic models. 10 P a g e S e m a n t i c M o d e l i n g P r o f i l e

11 The SCMP specification does not include the specification for mapping to other technologies, such mappings build on the SCMP. Such mappings may be done manually by a programmer or automated using Model Driven Architecture (MDA ) 4. A formal specification for mapping to description logic and OWL is in process of being standardized and published at: What semantic models don t assume This section discusses commitments and assumptions made in semantic models compared with other languages and logics, it is somewhat theoretical and may be skipped by the casual reader. Any application, database or inference engine makes some assumptions, or commitments about data when applied to the model. These assumptions may differ for various use cases or technologies. For this reason a semantic model is silent on these assumptions and leaves such choices up to the implementing systems. Open world or closed world the open world assumption (as used in OWL-DL) is that a model or dataset is incomplete, this impacts what can and can not assumed, for example in an open world assumption the lack of a customer in a data set is insufficient to assume some entity is not a customer. It is therefore o.k. to assume a customer exists if it makes other data consistent. A closed world assumption assumes data sets are complete for the purposes of any query or computation. The SCMP does not commit to either assumption. Constraint enforcement or proof theory Where a constraint is stated in a model, for example that only people have social security numbers, a constraint system (e.g. a SQL edit) will not allow incorrect data to be entered. A proof theory logic (e.g. OWL) will infer that anything (e.g. a Dog) must also be a person if assigned a SSN unless Dog and Person have explicitly been made disjoint. The SCMP does not commit to either assumption. Unique Name Assumption The unique name assumption is that things with different identifiers are different things (e.g. a primary key in SQL), the opposite (e.g. OWL) is that things with different identifiers may be assumed to be the same thing as a result of proof theory. The SCMP does not commit to either assumption. Single Classification Most implementation technologies that support inheritance (e.g. Java) only allow a class to have one supertype (single inheritance) and only allow an individual instance to have one type (single classification). Semantic models allow both multiple inheritance and multiple classification. Note that most ontology languages do support multiple inheritance and multiple classification. SCMP does not restrict inheritance. First order A first order logic (e.g. OWL-DL) does not allow statements to be made about other statements, rules or context. First order restrictions are introduced to make automation of inference engines more practical. Semantic models and higher order logics do not introduce first order constraints so that real world concepts like context, time, rules, obligations, permissions and policies can be represented. The above lack of commitment allows SCMP to be used to more directly model the domain, without being distorted by implementation concerns. When a semantic model is mapped to a specific technology or logic some or all of the above assumptions may be made and appropriate patterns applied to implement the commitment Semantic Models and Ontology Languages This section discusses the relationship between Semantic Models and various logics (such as OWL-DL), it is somewhat theoretical and may be skipped by the casual reader. 4 MDA: 11 P a g e S e m a n t i c M o d e l i n g P r o f i l e

12 Semantic Models are ontologies in that they represent concepts of a real or conceived world in a semantically precise way. Semantic Models differ from some ontology languages in intent and scope. For comparison we will focus on the Web Ontology Language (OWL-DL), which is an ontology language based on Description Logic. Note that, given particular assumptions, a semantic model can be used to generate an OWL ontology and likewise most OWL ontologies can be reverse engineered into a Semantic Model, but this does not make them the same thing. Note that OWL makes some commitments (assumptions) that Semantic Models do not (see section 1.1.6) Many Kinds of Logics Figure 3 Relationships Between Logics (John Sowa) What is sometimes not clear outside of the ontology expert community is that there are many kinds of logics. Different logics have different purposes, expressability, constraints, and focus. The logic expressed in OWL-DL is known as SRIOQ, each of those letters has a very specific meaning in formal logic that we will not explore here. In most cases, the reasons for these various logics is to allow efficient inference engines to be written that can exploit the ontologies to deduce new knowledge (perform inference). These inference engines, as any program, have limits and requirements. Some of the requirements include that the logic is decidable 5. If a logic is decidable it is possible to reach a conclusion from any model expressed in that logic in some finite time (even if that time is millennia). Compare this with, for example, Java where is it possible to write a program that never ends (has an endless loop). Just because a logic is not decidable does not mean that a particular model in that logic is not decidable (I thank John Sowa 6 for making that distinction clear to me). Other constraints put on logic for implementation reasons are that they are monotonic 7, we will not go into the details, but the impact is 5 Decidable: 6 John Sowa: 7 Non-Monotonic: 12 P a g e S e m a n t i c M o d e l i n g P r o f i l e

13 the same logics are defined to solve specific kinds of problems, a friend described them as puzzle solvers. These puzzle solvers can provide substantial capabilities and are a valuable part of the toolbox, but are limited in their ability to express concepts that are a reality in our everyday life Requirements for Semantic Model Logic To fulfill our goals of a semantic reference model that directly captures domain concepts we, of course, have to be able to express those concepts. The focus of a semantic model is capturing (and utilizing) these concepts as a reference, not necessarily using them directly to power inference engines (however, some inference is possible). These requirements include: Statements about rules and policies Statements about obligations and permissions Statements about time and when things are valid Contextual statements Statements of trust, confidence and possibility Assumptions and commitments (in section 1.1.6) should be made by applications, not the model The fancy terms for the above would be a non monotonic deontic higher order logic, inference on such a model is research material, yet they are normal business concepts that are handled by humans and our applications every day. However, there are also some advanced semantics that can be expressed in those logics that are not used in Semantic Models. Our goal is to capture concepts as a reference for more operational technologies and logics. There are also patterns that allow assumptions to be made such that a more operational ontology can be generated, this has been done for both Description-Logic and F-Logic. Likewise, operational schema for SQL, XML, JSON and other technologies can be generated (these are less bothered by logical concerns but have other limitation). The net effect is that Semantic Models would fall somewhere in the some second order constructs layer of logics, but given our purpose, this is not a problem it is a feature. 13 P a g e S e m a n t i c M o d e l i n g P r o f i l e

14 1.2 Essential Semantic Model While a semantic model may contain detail and precision to any level required, experience has shown that a very few kinds of concepts are used to define the essential 8 (or foundational) business meaning and structure of a semantic model. The following are the fundamental elements of any essential model: Models and sub-models as the definitional scope for concepts, each model representing a subject area of interest to stakeholders. The set of such models, connected and related, define a lattice of models that, together, model a domain. Models are defined as UML packages. Precise natural language definitions for concepts that capture stakeholder understanding but are carefully constructed to resolve ambiguity or conflict. Every concept has a definition. Hierarchies of the kinds of entities found in a domain, entities can include physical things like people or places as well as social constructs like a sale or ownership. Entities are represented as UML classes; no special stereotype is required. Hierarchies of roles entities play in various context, roles become the connective tissue between entities and relationships. Roles are defined using a SCMP stereotype of a class. Hierarchies of phases (or states) entities can be in. Phases help capture how things can change over time, such as person that could be a teenager or adult. Another example is an invoice that is paid or unpaid. 8 Term Essential Model suggested by David Hay P a g e S e m a n t i c M o d e l i n g P r o f i l e

15 Hierarchies of Relationships as the way entities and roles are connected. Relationships are defined using UML association and association classes. The following are help define the vocabulary of the domain so are included in the essential model but may not be used for more abstract essential models. Hierarchies of the attributes provide a next-level of detail but may be critically important to a domain. Attributes describe some characteristic or attribute of an entity, role or relationship. Attributes may or may not be considered part of the essential model. Hierarchies of categories define other ways stakeholders think about and classify entities. Enumerations, also called code lists define specific instances that may be important in a domain. Values and quantity kinds define the kinds of data that attributes may hold, such as Weight, Length or Currency. Most common quantity kinds and units can be found in pre-defined libraries. Experience has shown that the fundamental elements: models, definitions, entities, roles, phases, relationships and attributes form the framework on which the additional detail and precision of the semantic model are based. These are the concepts that define the vocabulary of the domain and how the concepts of that vocabulary are connected. With the essential model in place, additional semantic assertions can be made that enhance the precision of that model, help to validate it and provide additional benefits for leveraging automation and inference. The following sections defines how UML with conceptual extensions is used to represent the foundational network of concepts using classes, associations, and properties. Additional constraints, expressed as rules, are then attached to this basic framework to enhance semantic expression and the ability of automation to federate and analyze information about those concepts Extending the essential model The essential model defines the vocabulary of the domain and how the concepts of that vocabulary are connected. With the essential model in place, additional semantic assertions can be made that enhance the precision of that model, help to validate it and provide additional benefits for leveraging automation and inference. The modeling language for expressing these more precise semantics are defined in section Packages Representing Subject Areas Any realistic enterprise level semantic model will be substantial and can t be monolithic. Models typically will reuse generic concepts that cross domains. The full semantic model of a domain can be thought of as a lattice of interconnected subject areas, each subject area is modeled as a UML package where the <<Subject Area>> stereotype is optional and the default. The package contains a set of definitions for concepts that can be used, related to, or refined in other packages. Figure 4 Subject Area Package Example 15 P a g e S e m a n t i c M o d e l i n g P r o f i l e

16 The above example package Role Example contains definitions for concepts such as person and customer. A package is authored under the control of some authority, but may be used or extended by others. Subject Area packages may also contain other packages Classes representing Domain Entities Classes specify, or classify, a set of things, according to some set of rules or understanding. Classification is the essential mechanism of conceptualization we use. Classes specify a set of things belonging to that class this is called the class s extent. Each element of the class is an instance of that class it is something the class classifies. Classifications may be arranged in hierarchies from general to more specific. In the UML semantic model, a class is diagrammed as a box with a name at the top. In some cases, a definition is also shown inside or next to the box in a note form. Figure 5 Example of a Class The above example shows the class Incident and its definition. It should be noted that a class is a way to classify something. It is natural to classify something multiple ways. For example, we may classify a situation as also being a danger or, to someone else, an opportunity to do harm. This is different from many technology models (e.g. Java) that only allow something to be classified in one way and the classification is fixed. The basic assumption of a semantic model is that unless specified otherwise, something may be classified in any number of ways and those classifications may change over time Instances While not usually used in the definition of the semantic model, instances can also be shown in UML and are utilized to illustrate examples or to define well known instances, like the United States of America. Instances are important in understanding what classes classify. Since the model is conceptual, instances of classes are proxies, or signs, for the real thing in the world not data about them or other technology artifacts. Instances are also shown as a box, but have a : separating the name of the instance from its classes. Figure 6 Instance Example The above example shows a information about an instance named Joe Smith that is classified as a Person and a Victim Class Generalization Since Aristotle, classes have been arranged in hierarchies from most general concepts to more specific ones. In UML this is shown as a Generalization an arrow with a solid line from the more specific concept to the more general. All semantic elements that are kinds of classes can be generalized, this includes entities, roles, phases and relationships. Attributes can also be generalized, but use a different syntax. The more general class is 16 P a g e S e m a n t i c M o d e l i n g P r o f i l e

17 known as the Superclass (or Supertype) and the more specific the Subclass (or Subtype). Generalization has some specific semantic rules: Everything that is true about the superclass must be true about all its subclasses The extent of the subclass is a subset of the extent of the superclass All properties and associations that apply to instances of a class also apply to instances of all its subtypes In a semantic model, a class may have any number of superclasses or subclasses. In contrast, some technologies (Like XML Schema) limit the number of superclasses to one. Figure 7 Class Hierarchy Example The above example shows a class hierarchy with multiple levels. Note that all properties and associations defined for all superclasses of a class apply to that class. For that reason a complete understanding of a class and its potential properties must include such superclasses. A generalization is a subsumption relationship between a more general class and a more specific class. Subsumption means that every instance of the specific class is also an instance of the subsuming general class. Because of this subsumption relationship, the specific class inherits all of the conditions and capabilities of the more general class. For a simple example, if we define Futsal Team as a subclass of Soccer Team, then the set of individuals in Futsal Team must be a subset of the set of individuals in Soccer Team. Figure 8 Simple Generalization Example There are four variations on generalization described in the following subsections. The first variation corresponds to the example above: overlapping and incomplete subclasses. That variation is the default in both UML and Semantic Modeling. 17 P a g e S e m a n t i c M o d e l i n g P r o f i l e

18 1.2.5 UML Associations Representing Domain Relationships Relationships (modeled in UML using associations ) describe facts about how entities are related. Relationships are shown as lines between the classes that have related instances. At each end of the line is an association end property the association end describes how the instances of the class on the far end relate to those of the near end. If there are constraints to how many instances may be related, these are also shown. Since an association has at least two ends, the association may be read in any direction, but is the same fact. The association end properties are typically verbs or verb phrases, but in some cases noun phrases may be more appropriate based on the modeling style being uses In either case the name denotes the intent of the class at the other end of the line. Figure 19 Association Example The above example says that there are relations between actors and activities such that the actor performs the activity and the activity is performed by the actor. These are considered two ways to read the same fact. Like any fact, relations may be true for some period of time or in some specific situation. This combination of classes and associations with ends forms the basis for nouns and verbs common to human language. The terms used for the nouns and verbs should be both consistent with their semantics and resonate with stakeholders sometimes this is a bit of a challenge. In some cases the ends of the relation are sufficient to define it, in other cases it makes more sense to give the association a name and its own definition. Associations and association ends, like classes, can be part of a hierarchy UML Aggregation Kind UML Aggregation can be set to None, Shared or Composite. The values Shared or Composite indicate that the class of the aggregate side is a composite and that one of its parts is the other end. Shared and composite have no semantic difference within the profile. Figure 5 Aggregation Example A roof is part of a building and can t be a roof without a building to cover. Likewise a building must have at least one roof Association Classes as First Class Relationships In a semantic model any fact may have properties and may participate in other relationships. Of particular importance is the provenance of the fact where the fact came from and thus how much it can be trusted. Facts can also be time-bound, true for some period or only valid within some context. Where an association may have additional specific properties or may participate in other relationships, an association class is used. As implied by its name, an association class has both the properties of an association and the properties of a class. More complex associations between things use association classes. An association class is diagrammed as an association line and a class box with a dashed line between the association line and its class. While the association line and box may seem somewhat visually distinct they are the same concept. 18 P a g e S e m a n t i c M o d e l i n g P r o f i l e

19 Figure 21 Association Class Example The above example shows the Stakeholder Desirability relation. Between any situation and any stakeholder there can be some metrics as to how much that stakeholder desires or wants to avoid that situation. The Stakeholder Desirability association class represents these as properties of the association: net desirability, net harm, net benefit and net risk which can all be positive or negative reflecting a benefit or harm, respectively Attribute Properties Properties represent attributes or qualities inherent in something, such as size, weight or a time. Each property has a subject, the kind of thing that property can be a property of and a type for the kind of value that represents that quality. A property is a characteristic that an individual can have, or, as explained in a subsequent section, an individual must have to qualify as a particular kind of thing. Most properties are attributes of entities, roles or relationships and have some kind of value. The term for a property is usually expressed as a verb phrase, such as "Vehicle has weight Mass" or "Geographic Region identified by Address". Some methodologies use noun phrases for attribute property terms, such as birth date. Fundamental to the semantics of any attribute is the kind of thing that can have to characteristic defined by the attribute, this is sometimes called the attributes domain. Also fundamental is the type of value the attribute can have, sometimes called its type or range. A very few attributes may not have any specific domain or range these attributes are defined using an <<Anything>> type (see below). Semantic models do not assume that all attributes must be defined as part of the initial definition of a class or that all defined attributes are required for all application purposes or schema. Note that some methodologies initially define attributes without domains and ranges and then restrict them for a particular use we allow but do not recommend this pattern as it fails to capture fundamental semantics of the attributes. Most attributes have a <<Value>> as their type, such as a point in time or a mass (the use of primitive data types like int and string is discouraged in semantic models), usually expressed as a prepositional phrase, such as "Person born on Date" or a noun phrase, such as Person birth date Time Point. Figure 18 Example of Attribute Properties The above example shows that an animal has the qualities of birthdate, death date, physical sex, height and weight. Note that these is no assumption that these qualities may be known, required or that different data sources may or may not agree on them just that an animal has these qualities. Instances of properties are facts about the entity they describe. In semantic models, attributes are only used for qualities, never to relate different entities. 19 P a g e S e m a n t i c M o d e l i n g P r o f i l e

20 The type of an attribute is normally a data value of some kind, such as length or weight, attributes do not normally have entities as their types, but this is not prevented to allow for variation in modeling styles. Attribute properties may be diagrammed as a property within a class or at the end of an association that is only navigable on one way (using UML Navigable ). Where an attribute property is defined in the same scope as the class it may be defined within the box. Where an attribute is being added in another model it must be shown as an association. Figure 6 Example of property defined using an association A much smaller number of properties represent metadata, usually expressed as a noun phrase, such as "Anything description String" or "Anything see also URI". To represent metadata, this profile provides a stereotype called «Annotation Property» that can be applied to a standard UML property in a semantic model Roles Roles are facet classes that are expected to be dynamic and contextual, such as teacher, victim or president. A role is defined using a class with the <<Role>> stereotype and, optionally, a <<Role Of>> generalization. Implementation technologies should interpret roles as classifications that may be added to or removed from an instance over time and may be defined in a particular context. A role is usually required to be a role of some particular other class, for example a teacher is expected to be a role of a person (at least until a computer takes her job). The constraint of what a role must be a role of is defined using a <<Role Of>> stereotype of a generalization. A role will also frequently have a relationship with something where the multiplicity is at least one. For example, a person is a parent if they have at least one child. Many implementation languages don t have the capacity to represent roles, so roles are sometimes implemented is the single and unchangeable type of a class or DBMS table. The problem with this is that the same individual may not be connected across all their roles. Specifically representing roles allows the same individual to play multiple roles and for these roles to change this better reflects the reality of the world and the way we think about it. Figure 22 Role Example The above example shows that a social agent can be a person or organization and that either could be classified as being able to play the Supplier or Customer roles. Roles help to decouple concepts in models and specifically allow an instance to play multiple roles at the same time or over time. Roles, when combined with quantification constraints, clearly define the semantics of roles. For example, we could say that a victim must be a victim of some incident and an owner must own something. 20 P a g e S e m a n t i c M o d e l i n g P r o f i l e

21 There are various implementation patterns for roles; SCMP does not define a specific implementation pattern, such choices will be based on target technology and application requirements. Examples of such implementation patterns include defining a separate technology object for each instance of an entity playing a role, defining roles in separate graphs or using multiple classification. Roles may also be differentiated as being a role inherent in an entity (E.g. Joe is a pilot ) and roles with respect to some relationship (E.g. Joe is a pilot of flight UA940 ). with respect to will be explained in the next section Context of roles and with respect to Some roles reflect a generic capability or responsibility of an entity, examples would include capturing statements such as Joe is a Policeman Sue is a Pilot or Jill is a Parent. We could also say things about such generic roles like Sue is a good pilot Contrast such generic roles with roles specific to a situation such as Sue is a Pilot of Flight-UA100, such roles are dependent on both the bearer of the role and some relationship which defines the context of that role. Note that both could apply to the same individual, we could say Sue is a good pilot but piloted Flight UA100 badly. It is important to define roles with respect to a context where attributes or relationships of that role differ from situation to situation. For example, we may want to capture an employee ID as identifying attribute of a particular person with respect to a particular employer. The with respect to tag is an option tag for a <<Role>>. Where with respect to is defined, the role will have an independent identity comprised of both the bearer of the role (Sue in the above example) and the context of the role (FlightUA100 in the above example). Figure 7 With respect to example The above example shown modeling both a generic role (Pilot) and a role in the context of a relationship (Pilot of Flight). A person is either a pilot or not and as such can have total flight hours. A pilot of a specific flight can also have flight hours for each flight. Using common implementation patterns, there will be an instance of Pilot of flight for each combination of a person and a flight, where that person is the pilot of that flight. Some technologies (such as RDF or OWL) may allow generic roles like Pilot to utilize multiple classification to simply type the person as a pilot without creating another instance other technologies (Such as SQL) may require an additional instance. Note: In some cases there may be a tradeoff of using with respect to or a first class relationship (a UML association class) as both allow attributes and other relationships specific to a relationship. While the choice is somewhat stylistic, facts that are purely about the relationship may be better modeled about the relationship flight hours, above could be modeled either way. 21 P a g e S e m a n t i c M o d e l i n g P r o f i l e

22 1.2.9 Phases Phases are classes that are expected to classify an instance over a specific span of time or temporal condition, such as a teenager, Adult or Paid Invoice. A teenager is a person between the ages of 13 and 19 (inclusive) perhaps Adult is of age 20 or older. Phase may be considered a synonym for the State of something. A phase is defined as a class with the <<Phase>> stereotype. Phases use the <<Phase Of>> stereotype of a generalization to define what a phase must be a phase of. Figure 23 Phases of a person Like roles, phases help to decouple concepts in models and specifically allow an instance to be in multiple phases (or multiple roles) at the same time or over time. If an instance cannot be in two phases at the same time or be in a role and a phase a disjoint with constraint can be used to state that restriction. In the example above, the phases are disjoint Categories A <<Category>> is a facet of an instance that is a classification or division of people, events or things regarded as having particular shared characteristics. Categorization is typically contextual, potentially transient and may or may not be formally defined. As with all facets, categories are non-rigid. Something classified by a category must also be classified by an entity type. An entity may be classified by any number of categories and those categories may change over time. <<Category Of>> (like Role Of) is used to specify what kinds of thing may be so categorized. 22 P a g e S e m a n t i c M o d e l i n g P r o f i l e

23 Example Essential Model The following is a small example of a model utilizing all of the above concepts. Figure 8 Example Essential Model The above is an example essential model of a simple sale. A sale is made between a Supplier and a Customer, roles that can be played by people or organizations. Each sale has a transaction amount, date and a set of products sole, where Product is a role of any entity. Such an essential model should define the vocabulary of the domain and each concept should have a vetted business definition. The essential model should be used as the foundation for all documentation and discussion about the domain and any systems in the domain. If it doesn t work for those purposes, the model should be revised. 23 P a g e S e m a n t i c M o d e l i n g P r o f i l e

24 1.3 Enhanced Semantic Model Precision The essential model defines the concepts and vocabulary of a domain that has direct value. However, the meaning of concepts in natural language definitions is not fully captured in an essential model. Improving the semantic precision has a number of benefits: Models and data can be validation for consistency Business friendly interpretations of the model semantics can aid in stakeholder understanding Logical inference engines and rule based systems can leverage semantics to infer new knowledge Automation can more accurately forward engineer implementation from the semantic models The following sections define the modeling language for semantic precision Class Hierarchy Semantics Generalization semantics applies to all concepts based on classes and associations, this includes: Entities, Roles, Phases, and Relationships Overlapping and Incomplete Subclasses This variation is the default in Semantic Modeling. An instance can be a member of the superclass and / or any number of subclasses. In this sense, the classification of instances is incomplete sometimes an instance is classified by one or more specific subclasses, and sometimes it is not. For example, the diagram below shows four instances (represented by white diamonds). One is an instance of Manufacturer, one is an instance of Windshield Manufacturer, one is an instance of Car Manufacturer, and one is an instance of both Windshield Manufacturer and Car Manufacturer. Figure 9 An example of incomplete subclasses In both standard UML and in Semantic Modeling, incomplete and overlapping subclasses are shown with either no notation, or with the equivalent notation {incomplete, overlapping} near the generalization arrow. 24 P a g e S e m a n t i c M o d e l i n g P r o f i l e

25 Figure 10 Incomplete and overlapping subclasses in standard UML notation Disjoint and Incomplete Subclasses This variation means that an instance can only be classified by at most one of the disjoint classes. Disjoint classes cannot have any overlap in their instances. The diagram below shows three instances. One is an instance of Cat, one is an instance of Dog, and one is an instance of Animal. An instance classified as both Cat and Dog is impossible because there is no overlap between the two classes. In the most basic terms, an instance of a Cat cannot be an instance of a Dog, and vice versa. Figure 11 Disjoint Subclasses The following diagram shows an example of disjoint subclasses in standard UML notation. It shows that Dog, Cat, and Mouse are all subclasses of Animal. In addition, the standard UML {incomplete, disjoint} notation declares all of the subclasses to be incomplete and disjoint. Intuitively, an instance of the subclass Dog is an instance of the superclass Animal, but it cannot also be an instance of the Cat or Mouse subclasses. It is incomplete because there can be many more kinds of animals. Figure 12 Incomplete and disjoint subclasses in standard UML notation The profile also supports a dependency stereotyped as «Disjoint With» to specify that anything can be disjoint, even if they are not subclasses of a common super type. disjoint subclasses. For example, the class Animal has three disjoint subclasses, Cat and Dog. 25 P a g e S e m a n t i c M o d e l i n g P r o f i l e

26 Figure 13 Alternative «Disjoint With» Stereotype [CC7] Complete and Overlapping Subclasses This variation means that an instance can only be classified by at least one of the subclasses; it cannot be classified by only the superclass. Keep in mind that an instance of a subclass is indirectly an instance of a superclass at the same time. For example, the following diagram shows 7 instances. As various combinations of land, sea, air and space vehicles (and there can be more combinations) but every vehicle must be at least one of these classes (there can not be instances in the lite blue area). Figure 14 An example of complete overlapping subclasses The diagram below shows an example of complete and overlapping subclasses in standard UML notation. Figure 15 Complete & overlapping subclasses in standard UML notation 26 P a g e S e m a n t i c M o d e l i n g P r o f i l e

27 Disjoint and Complete Subclasses This variation means that an instance can only be classified by one of the subclasses. The instance cannot be classified as only the superclass, and it cannot be classified by two subclasses at the same time. For example, in the subsequent diagram, two instances are shown. One is an instance of Person, and one is an instance of Organization. There can be no instance of Social Agent that is not also an instance of one of the subclasses, and there can be no instance that is classified as both a Person and a Organization at the same time. Figure 16 Disjoint and complete instances The diagram below shows an example of disjoint and complete subclasses in standard UML notation. The diagram shows that Person and Organization are subclasses of Social Agent. In addition, the standard UML {complete, disjoint} notation declares that the subclasses are complete and disjoint Kinds of classes Figure 17 Disjoint and complete subclasses in standard UML notation The following are stereotypes that specialize the concept of UML classes. 27 P a g e S e m a n t i c M o d e l i n g P r o f i l e

28 Anything The stereotype «Anything» can be applied to class to indicate that is the universal class, everything implicitly has the type of all <<Anything>> classes, typically called Thing. Every such <<Anything>> class is equivalent to one topmost class ( ) of which all other classes are subclasses. Thus, a property of a class marked as «Anything» is inherited by all subclasses. In addition, while the name of a such a marked class is irrelevant, consistently naming such classes Thing in all semantic models avoids any confusion with normal classes. Figure 22 «Anything» Example The Semantic Modeling foundation model provides a default Thing that can be used or extended in any model Note: to add properties to the default Thing, one-way associations must be used Union A «Union» is a class that has an extent (set of instances) which is equivalent to the union of the extents of all types that specialize the Union (Subclasses). Specializing types shall include subtypes and types that realize the union. Note: UML realizations are included to support unions across external models because UML generalization cannot be used across external models due to the ownership of generalization. Unions may be named, but the name is optional. Unnamed unions are considered anonymous. Some methodologies do not permit anonymous classes but the profile does not prevent it. The following diagram states that an instance of a Person may have a value of type Cat or Dog for the cares for property. The diagram also states that an instance of a Cat or a Dog may have a value of type Person for the cared for by property Intersection Figure 23 An anonymous union class An «Intersection» is a class that has an extent (set of instances) equivalent to the intersection of the extents of all supertypes (remember that the extend of a class is all instances which have that type). Intersection is a stronger statement than a subtype, as a subtype may be a subset of the intersection. An instance of all the supertypes implies an instance is also an instance of the intersection type. For intersection, The Semantic Modeling profile considers UML generalization and UML realization equivalent. This is due to ownership and legacy considerations in UML. Generalization is the preferred representation. 28 P a g e S e m a n t i c M o d e l i n g P r o f i l e

29 Quantity Kinds and Unit Types Fundamental to understanding and describing something is physical and other qualities such as temperature, length and color. Many data models fail to capture units of measure explicitly which can and has[1] resulted in dramatic systems failures. A concept for somethings weight should properly be typed by a measure of weight, not an int or real which are just ways to represent numbers without knowing what they mean. Of course there needs to be numbers, but in relation to their units. In that there are different units that can represent the same kind of measure, such as degrees Celsius and degrees Fahrenheit can represent the same temperature an abstraction is used above like units. The abstraction for a measurable unit is called a <<Quantity Kind>>. Examples of quantity kinds include Length, mass, temperature, frequency, etc. As any element of measurement data must be specific to a specific unit in a specific data exchange, the <<UnitType>> stereotype is used to define a unit for a quantity kind. A <<Represents>> stereotype of generalization (Sometimes diagrammed as a green arrow) is used to say that the unit represents the quantity kind. Figure 9 Quantity Kind and Unit Type Example In the example above, the Area quantity kind can be represented by (the green lines) Square Meter, Square Feet or an Acre. One unit may be nominated as the Base Unit and will be used to express conversion factors between the units. As per SI specifications, the Square Meter is the base unit. Note: By convention quantity kinds are used in fully conceptual models whereas units are used in data models. Note 2: Common Quantity Kinds and Units are available in a foundation model on SemanticModels.org Enumerations UML Enumerations may be used to define a value type with a fixed set of simple members where each member just has a name and a definition. Enumerations are also known as Code Lists. 29 P a g e S e m a n t i c M o d e l i n g P r o f i l e

30 Figure 10 Days of Week as an Enumeration Enumerations are convenient but limited. Enumerations can also be specified in a UML package containing UML instance specifications. Figure 11 Enumerates Example Days of week specified as a class with instances in a package Equivalent Class An «Equivalent Class» stereotype applied to a generalization can specify equivalence between two classes. Class equivalence expresses a generalization relationship stereotyped as «Equivalent Class». Tools may optionally draw this with a double-headed arrow. The following figure shows two equivalent classes in a diagram. Figure 36 Two Equivalent Classes in the Semantic modeler In the example, the equivalence class arrow defines that the two classes are semantically equivalent to each other. Equivalent class is particularly useful for joining independently conceived semantic models. 30 P a g e S e m a n t i c M o d e l i n g P r o f i l e

31 1.3.3 Property Semantics Subject (domain) and type (range) of an attribute The Semantic Modeling profile of UML interprets the owner (defining class) of an attribute definition as the subject of that attribute (its domain). E.g. has weight can only be an attribute of a Physical Object, Physical Object is the subject (or domain) of has weight. Attribute ownership is not interpreted as slots in an object. Attribute values may or may not be independent of the instance that defined them. Attributes also have a required type (or range ), usually a <<Value>>. The type constrains the kind of value that can be the value of the attribute. E.g. has weight may heave a type of Mass. Both the subject and type of attributes may be constrained in subtypes using Subsets or Redefines Cardinality Cardinality defines how many value of a property may exist for a particular subject instance. For example, how many ages can a person have? The obvious answer is that a person can have at most one age at any one point in time. Thus cardinalities represent the number of instances at any one time regardless of how it is represented. Cardinality defines how many values a property (attribute or end of a relationship) may have. A cardinality of one or more defined for a property requires that an instance of the related element must exist for an instance of the domain (owning class) of that property or association end to be valid. For example, a living person must have exactly one living brain. UML allows the cardinality of a property to be left unspecified, in which case it defaults to Note that conceptual models do define what you may or must know or what the requirements of a data model are they define what must be true about the world as it is conceived. Figure 12 Relationship Cardinality Example The above means that a building must have one or more roofs and a roof can only be the roof of one building. Figure 13 Example Attribute Cardinality Since so explicit cardinality is specified, the above means that a Communications Network must have exactly one provides security level value Property Hierarchies Like class hierarchies, attributes and association ends (we will just call both properties from now on) can also be arranged in hierarchies of more or less specific properties. In UML, property hierarchies are represented using either UML Subsets or Redefines constraints. A property subsets or redefines is shown next to its name in in the diagram (Note that by convention this is not shown on essential diagrams, only the primary definition of the property). If a property completely subsumes the other in a particular context it uses a Redefines that is the 31 P a g e S e m a n t i c M o d e l i n g P r o f i l e

32 redefining and redefined properties have the same set of values. If the more general concept can also be used in the context a Subsets is used. Figure 20 Example of Association End Hierarchy using Subsets The above example shows that the physically within and physically contains properties are specializations of the is in and contains concepts, respectively. Since Subsets is used, is in and contains may also be used, perhaps for other perspectives. Figure 14 Redefines Example The above example shows that automates redefines has control over, automates replaces has control over for an Automated Control relationship Property Restrictions It is common for an attribute or end of an association to have more specific constraints based on the property having a more specific subject than its base definition. Such a property is a <<Restriction>> of the more general use of the same property using either Subsets or Redefines. A <<Restriction>> always has the same name as its base property or no name at all. The constraints that can be refined in a restriction include: The property type The property cardinality Property {id} 32 P a g e S e m a n t i c M o d e l i n g P r o f i l e

33 A <<Restriction>> of a property using Subsets asserts that some of the properties (with the association domain) must meet the stated constraints. A <<Restriction>> of a property using Redefines asserts that all of the property values (with the association domain) must meet the stated constraints. A property is not limited to a minimum and a maximum cardinality (known as multiplicity) for just one type. A property can have a multiplicity for a superclass, while at the same time having a more specific multiplicity for one or more subclasses of that superclass. This type of constraint is an assertion that, among other possible values, the number of values of one of these subclasses is between some minimum and maximum cardinality. Figure 27 Phone constraint: A phone must have a hangup button In the above example we may say a phone must have one or more buttons with a has button property but exactly one of those buttons must be the hang up button. We would then define an <<Restriction>> property with the type hang up button that subsets the has button property with a cardinality of 1. If we wanted the Hangup Button to also define a new property, we would give that property a name it would not be a restriction. Figure 28 Hangup button with new property The <<Restriction>> may be differentiated from a new property (has hangup button) that is a subset of has button as defined in the above example. Where all values of a property must be constrained in a specialized property, UML {redefines} is used with a <<Restriction>>. Figure 30 Example of redefines The example above shows a simple phone that has exactly two buttons and they must be an answer button and a hangup button. Since redefines is used, no other buttons are allowed. 33 P a g e S e m a n t i c M o d e l i n g P r o f i l e

34 Inferring a type from its properties The type of an instance can be asserted (and inferred if the technology allows) based on specific property values using the <<Sufficient>> and <<Necessary and Sufficient>> stereotypes. The semantics of what qualifies a type is defined by SCMP but the choice to perform inference is an implementation option outside of the scope of SCMP. The <<Sufficient>> stereotype is used to classify instances based on existing property values and types. A class with at least one <<Sufficient>> condition allows an instance to be classified by the type if (a) the all sufficient properties have at least one value and (b) the instance is classified by all the <<Sufficient>> types and (c) would violate any cardinality constraints if so classified. All properties with a cardinality of one or more are necessary conditions, therefore the <<Necessary and Sufficient>> stereotype also asserts that the minimum cardinality of a property must be one or more. <<Sufficient>> and <<Necessary and Sufficient>> when applied to a generalization or property with a minimum cardinality of one are equivalent. Figure 33 Phone example for sufficient The diagram above defines a phone as any electronic giz that has a hangup button. The existence of a hangup button is sufficient to know an electronic giz is a phone. Something with a hangup button that was not an electronic giz would not be considered a phone. The diagram below shows that when an instance with the property has contract with satisfies specific multiplicity ( 1..* ) and type constraints (of type Steering Wheel Manufacturer and Windshield Manufacturer ) for the property s values, the instance meets necessary and sufficient conditions to be a member of the class Car Manufacturer. Therefore, an inferencing engine could classify this as an instance of the class Car Manufacturer. Also, an instance meeting all of the necessary and sufficient conditions is enough to distinguish instances of the class Car Manufacturer from its parent class Manufacturer. Figure 35 An example of necessary and sufficient condition [CC35] 34 P a g e S e m a n t i c M o d e l i n g P r o f i l e

35 UML {id} The property {id} may be set of a property to indicate that the property is part of the identity of the class that is the subject (domain) of the property or a property restriction. Figure 15 Identity Example The context in which a unique identifier is unique within is part of the identity of the identifier Property Chain A property chain is useful for composing a property from two or more other properties that are traversed to form the chain. A <<Property Chain>> defines the property with reference to the other properties. The property chain allows you to navigate from a starting property (the one with the stereotype «Property Chain») through a chain of properties that take a path through the same or multiple other classes. A property chain is an ordered list of linked properties that determine the value of the stereotyped property. The following example describes a Person class that has two subclasses Female Person and Male Person, and four properties has parent, has father, has uncle, and has brother. The stereotype of the property has uncle will be «Property Chain», and the tagged value is chain = has father, has brother. (Note that the «Property Chain» stereotype is suppressed in this diagram, but the tagged values are not.) Equivalent Property Figure 34 Property Chain Example An «Equivalent Property» allows you to represent properties that have the same meaning. You can make a property equivalent to two or more other properties by applying the stereotype «Equivalent Property» to the 35 P a g e S e m a n t i c M o d e l i n g P r o f i l e

36 referenced properties and the tagged value equivalent to the equivalent properties. <<Same As>>, when applied to properties, has the same meaning as «Equivalent Property» Enumerates An <<Enumerates>> dependency asserts that the supplier of the dependency is a type and the client of the dependency is a set of instances of package containing a complete set of possible instance specifications. In this way, <<Enumerates>> is more general than a UML Enumeration because it can enumerate more than just UML data types Transitive Property <<Transitive>> applies between successive members of a sequence of the same property, it must also apply between any two members taken in order. For instance, if A is larger than B, and B is larger than C, then A is larger than C Symmetric Property A Symmetric property is a property for which holds that if the pair (x,y) is an instance of P, then the pair (y,x) is also an instance of P. For example, if "attachedto" is symmetric, then if A is attachedto B, B is attachedto A Synonym <<Synonym>> defines an alternate name for the annotated elements of the comment. The alternate name is the body of the comment. The alternate name will not be the "preferred name" of the element Annotation The SCMP provides a way to create metadata about any element using annotations. One can annotate classes, properties, and models using an open-ended system of annotation properties. An annotation property defines information about the model (metadata), not about the subject domain. A property can be made an annotation 36 P a g e S e m a n t i c M o d e l i n g P r o f i l e

37 property using the «Annotation Property» stereotype on a UML property. Note that creating an annotation property of <<Anything>> can annotate any class. Every «Annotation» is a textual value for an «Annotation Property». An annotation describes some subject using an annotation property and a (usually textual) value. An annotation should specify a tagged value called value for that refers to an «Annotation Property». For example, the following diagram illustrates several UML comments stereotyped with «Annotation» UML Constraints Figure 22 Annotation Examples[CC15] Where built-in semantic capabilities are not sufficient, constraints may be added to any essential model element using either the OCL-2 9 or ALF 10 expression formats. Note that the ability to process constraints is optional and may not be supported by some tools or in some technologies. 9 OCL: 10 ALF: 37 P a g e S e m a n t i c M o d e l i n g P r o f i l e

38 Figure 16 Constraint Example In the above example has weight must be greater than zero for a physical entity. 1.4 Other Stereotypes Same As <<Same As>> is a stereotype of dependency that asserts that two elements in a model mean the same thing and/or are the same thing External Reference <<External Reference>> defines tags to reference an external authority for the definition of an element in a model. The tags are: external reference: A URI External term: A specific term defined in the external reference Resource <<Resource>> defines a unique identifier or default prefix to a resource using the following tags: IRI: A unique URI for the resource Prefix: A string that may be used as an abbreviation for the resource <<Represents>> {TODO} Represents asserts that a particular type found in a concrete (logical or physical) model represents information about a real or abstract concept in a conceptual reference model. By default <<Represents>> does not implement a mapping, it defines what elements can be mapped and thus restricts mappings. For simple one-one mappings there is an optional tag for <<Represents>> to <<map-all>> known instances of one Class to another. Example Figure 26 Activity Mapping Summary Example The above example shows that an ActivityType from NIEM-Core represents an Event as defined in the threat/risk conceptual model. By convention we show the represents dependency as a green dashed. Representations provide the most abstract level of mapping. This diagram also shows that that there is a more detailed activity Match Rule for the same types which will map the properties and relationships between these types. What this means is that some ActivityType instances represent some information about events in real world activities. Note that ActivityType may also represent other things, but that not shown in this example. Based on the SMIF mapping riles, this <<Represents>> also implies that relationships involving an event can be validly mapped to relationships involving an activity and that properties of an occurrence can validly be mapped to properties of an activity, <<Represents>> relations provide type-safety for mappings. What this does not say is that ActivityType and Event are equivalent and can necessarily be mapped How they are mapped is detailed in mapping rules. However, if the <map-all> tag of <<Represents>> is set true then 38 P a g e S e m a n t i c M o d e l i n g P r o f i l e

39 ActivityType and Occurrence will be asserted as being mapped 1..1, bidirectionally (mapping of types and properties is considered independent, each property must also be mapped). Note that <map-all> implies nothing about the properties and relationships, only the mapped types (each type, property and relationship is an independent concept that is mapped independently). Figure 27 {bidirectional} Example In the figure above, all UML classes stereotyped as <<Role>> will be mapped to the Role class in the SMIF model. 1.5 Kinds of Models A UML package may be stereotyped to define the intent of the model as: <<Concept Model>> - a semantic concept model <<Logical Model>> - a semantic model representing a design, not a domain <<Information Model>> a semantic model representing a logical information model. All sub-packages are considered to have the same model kind as the parent package, unless another model kind is applied UML Features with no Semantic Model Interpretation The following UML features of properties are ignored in a semantic model: Visibility Is read only Is static Is derived Is Derived Union Association end ownership 39 P a g e S e m a n t i c M o d e l i n g P r o f i l e

40 1.6 Semantic Concept Modeling Profile (SCMP) Reference The Semantic Concept Modeling Profile defines stereotypes and constraints to enable UML to represent concepts about real or conceived worlds Semantic Concept Modeling Profile (SCMP) Diagram Stereotypes Figure 1 SCMP Semantic Concept Modeling Profile for UML Stereotype Metaclass Properties Description Annotation COMMENT ANNOTATION PROPERTY An <<Annotation>> comment provides a textual "body" as a "value for" one <<Annotation Property>> describing the annotatedelement(s). Annotation Property PROPERTY An <<Annotation Property>> is a kind of <<Resource>> that asserts a property represents metadata rather than assertions about the subject domain. 40 P a g e S e m a n t i c M o d e l i n g P r o f i l e