Professional Documents
Culture Documents
The material in this document details an Object Management Group specification in accordance with the terms, conditions and
notices set forth below. This document does not represent a commitment to implement any portion of this specification in any
company's products. The information contained in this document is subject to change without notice.
LICENSES
The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up,
worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version.
Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the
included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any
computer software to the specification.
Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up,
non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and
distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this
specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission
notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be
copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for
commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates
without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the
specifications in your possession or control.
PATENTS
The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of
an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by
any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its
attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves
against liability for infringement of patents.
Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and
statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered
by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including
photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.
DISCLAIMER OF WARRANTY
WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN
ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE
NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF
MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT
SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR
ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL,
RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY
ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF
THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
The entire risk as to the quality and performance of software developed using this specification is borne by you. This
disclaimer of warranty constitutes an essential part of the license granted to you to use this specification.
Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The
Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the
Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of
the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and
its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the
Object Management Group, 140 Kendrick Street, Needham, MA 02494, U.S.A.
TRADEMARKS
MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered
trademarks of the Object Management Group, Inc., and Object Management Group™, OMG™ , Unified Modeling
Language™, Model Driven Architecture Logo™, Model Driven Architecture Diagram™, CORBA logos™, XMI Logo™,
CWM™, CWM Logo™, IIOP™ , IMM™ , MOF™, OMG Interface Definition Language (IDL)™, and OMG Systems
Modeling Language (OMG SysML)™ are trademarks of the Object Management Group. All other products or company
names mentioned are used for identification purposes only, and may be trademarks of their respective owners.
COMPLIANCE
The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is
and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use
certification marks, trademarks or other special designations to indicate compliance with these materials.
Software developed under the terms of this license may claim compliance or conformance with this specification if and only if
the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software
developed only partially matching the applicable compliance points may claim only that the software was based on this
specification, but may not claim compliance or conformance with this specification. In the event that testing suites are
implemented or approved by Object Management Group, Inc., software developed using this specification may claim
compliance or conformance with the specification only if the software satisfactorily completes the testing suites.
OMG’s Issue Reporting Procedure
All OMG specifications are subject to continuous review and improvement. As part of this process we
encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by
completing the Issue Reporting Form listed on the main web page http://www.omg.org, under
Documents, Report a Bug/Issue (http://www.omg.org/technology/agreement.htm).
Table of Contents
Preface ........................................................................................................... xi
1 Scope .............................................................................................................. 1
2 Conformance .................................................................................................. 2
3 Normative References ................................................................................... 3
4 Terms and Definitions ................................................................................... 5
5 Symbols .......................................................................................................... 8
6 Additional Information ................................................................................... 9
6.1 Changes to Adopted OMG Specifications .......................................................... 9
6.2 How to Read This Specification ........................................................................ 10
6.3 Proof of Concept ............................................................................................... 11
6.4 Acknowledgements ........................................................................................... 11
7 Usage Scenarios and Goals ........................................................................ 13
7.1 Introduction ....................................................................................................... 13
7.2 Perspectives ..................................................................................................... 13
7.2.1 Model-Centric Perspectives .......................................................................................... 14
7.2.2 Application-Centric Perspectives .................................................................................. 15
7.3 Usage Scenarios ............................................................................................... 16
7.4 Business Applications ....................................................................................... 17
7.4.1 Run Time Interoperation ............................................................................................... 17
7.4.2 Application Generation ................................................................................................. 18
7.4.3 Ontology Lifecycle ........................................................................................................ 19
7.5 Analytic Applications .......................................................................................... 20
7.5.1 Emergent Property Discovery....................................................................................... 20
7.5.2 Exchange of Complex Data Sets .................................................................................. 20
7.6 Engineering Applications .................................................................................. 21
7.6.1 Information Systems Development ............................................................................... 21
7.6.2 Ontology Engineering ................................................................................................... 21
7.7 Goals for Generic Ontologies and Tools ........................................................... 22
OMG member companies write, adopt, and maintain its specifications following a mature, open process. OMG's
specifications implement the Model Driven Architecture® (MDA®), maximizing ROI through a full-lifecycle approach to
enterprise integration that covers multiple operating systems, programming languages, middleware and networking
infrastructures, and software development environments. OMG's specifications include: UML® (Unified Modeling
Language™); CORBA® (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel);
and industry-specific standards for dozens of vertical markets.
OMG Specifications
As noted, OMG specifications address middleware, modeling and vertical domain frameworks. A catalog of all OMG
Specifications is available from the OMG website at:
http://www.omg.org/technology/documents/spec_catalog.htm
Middleware Specifications
• CORBA/IIOP Specifications
• CORBA Component Model (CCM) Specifications
• Data Distribution Service (DDS) Specifications
• Specialized CORBA Specifications
Language Mappings
• IDL / Language Mapping Specifications
• Other Language Mapping Specifications
Platform Independent Model (PIM), Platform Specific Model (PSM) and Interface Specifications
• OMG Domain Specifications
• CORBAservices Specifications
• CORBAfacilities Specifications
• OMG Embedded Intelligence Specifications
• OMG Security Specifications
All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG
specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format,
may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. at:
OMG Headquarters
140 Kendrick Street
Building A, Suite 300
Needham, MA 02494
USA
Tel: +1-781-444-0404
Fax: +1-781-444-0320
Email: pubs@omg.org
Certain OMG specifications are also available as ISO standards. Please consult http://www.iso.org
Typographical Conventions
The type styles shown below are used in this document to distinguish programming statements from ordinary English.
However, these conventions are not used in tables or section headings where no distinction is necessary.
Helvetica/Arial - 10 pt. Bold: OMG Interface Definition Language (OMG IDL) and syntax elements.
Note – Terms that appear in italics are defined in the glossary. Italic text also represents the name of a document, specification,
or other publication.
Issues
The reader is encouraged to report any technical or editing issues/problems with this specification to http://www.omg.org/
technology/agreement.htm.
This specification represents the foundation for an extremely important set of enabling capabilities for Model Driven
Architecture (MDA) based software engineering, namely the formal grounding for representation, management,
interoperability, and application of business semantics. The ODM specification offers a number of benefits to potential
users, including:
• Options in the level of expressivity, complexity, and form available for designing and implementing conceptual
models, ranging from familiar UML and ER methodologies to formal ontologies represented in description logics or
first order logic.
• Grounding in formal logic, through standards-based, model-theoretic semantics for the knowledge representation
languages supported, sufficient to enable reasoning engines to understand, validate, and apply ontologies developed
using the ODM.
• Profiles and mappings sufficient to support not only the exchange of models developed independently in various
formalisms but to enable consistency checking and validation in ways that have not been feasible to date.
• The basis for a family of specifications that marry MDA and Semantic Web technologies to support semantic web
services, ontology and policy-based communications and interoperability, and declarative, policy-based applications in
general.
The specification defines a family of independent metamodels, related profiles, and mappings among the metamodels
corresponding to several international standards for ontology and Topic Maps definition, as well as capabilities supporting
conventional modeling paradigms for capturing conceptual knowledge, such as entity-relationship modeling.
The ODM is applicable to knowledge representation, conceptual modeling, formal taxonomy development and ontology
definition, and enables the use of a variety of enterprise models as starting points for ontology development through
mappings to UML and MOF. ODM-based ontologies can be used to support:
• specification of expressions that are the input to or output from inference engines.
• specification of translation and transformations between the notations used by heterogeneous computer systems,
• free logics,
• conditional logics,
• methods of providing relationships between symbols in the logical “universe” and individuals in the “real world,”
• issues related to computability using the knowledge representation formalisms represented in the ODM (e.g.,
optimization, efficiency, tractability, etc.).
There are several compliance points distinguished for the Ontology Definition Metamodel. These include:
1. None or Not Compliant, meaning that the application in question is not compliant with a particular metamodel, as
defined by the metamodel itself, the abstract syntax, well-formedness rules, semantics, and notation specified for a
particular package or set of packages.
2. Compliant, meaning that the implementation fully complies with the abstract syntax, well-formedness rules,
semantics and notation of a particular package or set of packages.
3. Interchange, indicating that the implementation provides compliance as specified in [2], and can exchange
metamodel instances using ODM package conformant XMI.
There are several possible entry points for implementations that want to provide/claim minimal compliance with the
ODM. These require compliance with one of the following base metamodel packages:
• RDFBase Metamodel Package (RDFBase is a sub package of the Resource Description Framework (RDF) Metamodel
Package)
For a given implementation to claim ODM compliance, it must be Compliant, as defined in 2, above, with one of these
three packages.
There are several compliance options available to vendors for the RDF Metamodel Package. These include:
• RDFBase Only - as implied above, this package contains the set of elements required for core RDF support, such as is
necessary to support a triple store implementation; the focus here is on the set of constructs defined in the RDF
Concepts and Abstract Syntax [RDF Concepts] document.
• RDFBase + RDFWeb - provides core RDF support and fits these concepts to the World Wide Web.
• RDFBase + RDFS - moves the implementation focus from core RDF to RDF Schema, as specified in [RDF Schema].
• RDF - meaning, the implementation supports all of the concepts defined in the three sub packages, which represents
RDF Schema fitted to the Web.
There are two possible compliance points for the OWL Metamodel Package. Each of these requires support for the entire
RDF package, including the RDFWeb component. They include:
• OWLBase + OWLDL - focus is on a description logics application that constrains an ontology in turn for DL
decidability.
• OWLBase + OWLFull - focus is on more expressive applications rather than on decidability of entailment.
OWLBase + OWLDL for the Semantic Web (requires RDF) None, Compliant , Interchange
OWLBase + OWLFull (requires RDF) None, Compliant , Interchange
UML Profile for OWL (requires UML Profile for RDF) None, Compliant , Interchange
3 Normative References
The following normative documents contain provisions which, through reference in this text, constitute provisions of this
specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply.
[ISO 646] ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information
interchange.
[ISO 2382] ISO/IEC 2382-15:1999, Information technology -- Vocabulary -- Part 15: Programming
languages.
[ISO 10646] ISO/IEC 10646:2003, Information technology -- Universal Multiple-Octet Coded Character
Set (UCS).
[ISO 14977] ISO/IEC 14977, Information technology -- Syntactic metalanguage -- Extended BNF.
[ISO 24707] ISO/IEC FDIS 24707:2007(E) Information technology – Common Logic (Common Logic) –
A framework for a family of logic-based languages. Available at http://cl.tamu.edu/.
[MOF] Meta Object Facility (MOF) Core Specification, Version 2.0. OMG Specification, formal/06-
01-01. Latest version is available at http://www.omg.org/docs/formal/06-01-01.pdf.
[XMLNS] Namespaces in XML; W3C Recommendation, 14 January 1999. Latest version is available at
http://www.w3.org/TR/1999/REC-xml-names-19990114/.
[XTM] ISO/IEC FCD 13250-3: Topic Maps – XML Syntax, 2006-05-02. Latest version is available at
http://www.isotopicmaps.org/sam/sam-xtm/.
Entity-Relationship (ER)
An ER (entity-relationship) diagram is a graphical modeling notation that illustrates the interrelationships between entities in a
domain. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to
represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes.
universe of discourse
A non-empty set over which the quantifiers of a logic language are understood to range. Sometimes called a “domain of
discourse.”
5 Symbols
CL Common Logic
DL Description Logics
ER Entity-Relationship
SW Semantic Web
TM Topic Maps
6 Additional Information
MOF 2.0 [MOF] reuses and extends certain core packages from the UML infrastructure library, including the
Core::Abstractions package, wherein instance specification is defined. Essential MOF (EMOF) merges the Core::Basic
package, including the definition of instance specification from the Core::Abstractions package in UML Infrastructure,
with several new capabilities, including MOF Reflection. Section 12.1 in the MOF 2.0 specification explicitly reuses this
definition, by stating “EMOF reuses the Basic package from UML 2.0 Infrastructure Library as is for metamodel structure
without any extensions, although it does introduce some constraints.” and in 12.2 “The description of the model elements
is identical to that found in UML 2.0 Infrastructure and is not repeated here.” The set of constraints introduced in section
12.4 makes no mention of instances or instance specification, thus, the metamodel structure reused from UML is
unchanged with regard to instances and, in particular, their definition with regard to multiple classification.
There are at least three places in the MOF specification that do not support runtime instances modeled by instance
specifications, as described above, where:
• The Semantic Domain model for Constructs, Figure 15.1 in the MOF specification, omits the relationship between an
InstanceSpecification and its classifier(s).
• In the same figure, the classifier association end from ClassInstance to Class has a multiplicity of 1 instead of 1..*.
The authors consider this to be a problem in the MOF specification, as documented in issue #9466, and expect it to be
addressed in future revisions of MOF, notably, through the emerging “SMOF” or Semantic MOF RFP. As a result, the
normative metamodels contained herein presume support in MOF (SMOF) for multiple classification. Annex F includes
work-arounds for the issues we have uncovered related to this problem, however, for those vendors who choose to
implement the ODM before this problem is adequately addressed in a subsequent version of the MOF specification.
Chapter 10 describes a set of MOF metamodels for developing Resource Description Framework (RDF) vocabularies
(normative).
Chapter 11 describes a set of MOF metamodels for developing Web Ontology Language (OWL) ontologies (normative).
Chapter 12 describes a MOF metamodel for developing more expressive, first-order logic (FOL) ontologies in the
Common Logic (CL) family of languages (normative).
Chapter 16 provides a mapping between UML and OWL using MOF QVT. (informative)
Chapter 17 provides a mapping between Topic Maps and OWL using MOF QVT. (informative)
Annex A describes model library elements (M1) necessary for use with the RDF and OWL metamodels, and related but
independent library elements for use with the RDF and OWL profiles. (normative)
Annex E discusses issues related to making mappings informative rather than normative components of this specification.
(informative)
Annex F provides work-arounds for the limitations imposed on the RDF and OWL metamodels due to the MOF multiple
classification problem discussed in Section 6.1. (informative)
Annex H provides a short tutorial on the use of MOF QVT and its application in this specification. (informative)
• Web-KB is a non-MOF-based implementation of many of the concepts represented in this specification. It is available
for live demonstration on the Internet at www.webkb.org.
• Parts of the model presented in this specification were implemented using DSTC’s dMOF product (MOF 1.3) and
DSTC’s TokTok product (HUTN 1.0) to validate the expressive power of the model.
IBM has developed the following tools that in part validate portions of this specification:
• IBM Semantics Toolkit is a toolkit for storage, manipulation, query, and inference of ontologies and corresponding
instances. It is available for download at http://alphaworks.ibm.com/tech/semanticstk.
• EODM is a tool for manipulation of and inference over OWL ontologies and RDF vocabularies, using EMF-based
Java APIs generated from the OWL and RDFS metamodels. It is available for download at http://alphaworks.ibm.com/
tech/semanticstk. EODM was released as an open-source Eclipse Modeling Framework subproject (contact:
xieguot@cn.ibm.com), which may be replaced by a new ODM project in the MDT family of Eclipse projects later this
year.
Sandpiper Software has been developing technologies and tools to support UML-based knowledge representation since
1999. Sandpiper has developed the following products that validate parts of this specification:
• Visual Ontology Modeler (VOM) v1.5 is a UML 1.x/MOF 1.x compliant add-in to IBM Rational Rose, enabling
component-based ontology modeling in UML with support for forward and reverse engineering of OWL ontologies.
• Next generation support for UML2, MOF2, and ODM compliance for RDFS/OWL and CL ontologies, and a CL
constraint editor are under development, including migration to Eclipse/EMF, IBM Rational Software Architect
(RSA), and integration with other UML2-compliant modeling environments such as No Magic’s MagicDraw tool.
• The ODM metamodels and profiles reflected in this ODM 1.0 specification will be provided as a basis for open source
development to the new Eclipse MDT ODM project later this year (2008).
6.4 Acknowledgements
The following companies submitted this specification:
• IBM
• Adaptive, Inc.
• AT&T Government Solutions
• France Telecom
• Gentleware AG
• Hewlett-Packard Company
• Hyperion
• IKAN Group
• Institut AIFB, Universität Karlsruhe (TH)
• John Deere
• MetLife
• No Magic
• Raytheon Company
7.1 Introduction
The usage scenarios presented in this section highlight characteristics of ontologies that represent important design
considerations for ontology-based applications. They also motivate some of the features and functions of the ODM and
provide insight into when users can limit the expressivity of their ontologies to a description logics based approach, as
well as when additional expressivity, for example from first order logic, might be needed. This set of examples is not
intended to be exhaustive. Rather, the goal is to provide sufficiently broad coverage of the kinds of applications the ODM
is intended to support so that ODM users can make informed decisions when choosing what parts of the ODM meet their
development requirements and goals.
This analysis can be compared with a similar analysis performed by the W3C Web Ontology Working Group (W3C
2003). We believe that the six use cases and eight goals considered in W3C (2003) provide additional, and in some cases
overlapping, examples, usage scenarios, and goals for the ODM.
7.2 Perspectives
In order to ensure a relatively complete representation of usage scenarios and their associated example applications, we
evaluated the coverage by using a set of perspectives that characterize the domain. Table 7.1 provides an overview of
these perspectives.
Table 7.1 - Perspectives of Applications that Use Ontologies Considered in this Analysis
Source of Structure Passive (Transcendent) – structure Active (Immanent) – structure emerges from
originates outside the system data or application
Degree of Formality Informal, or primarily taxonomic Formal, having rigorously defined types,
relations, and theories or axioms
Model Dynamics Read-only, ontologies are static Volatile, ontologies are fluid and changing.
Instance Dynamics Read-only, resource instances are Volatile, resource instances change
static continuously
Control / Degree of Externally focused, public (little or no Internally focused, private (full control)
Manageability control)
An ontology can also be used in a software development process in different ways. The perspectives that reflect how an
ontology participates in the software development process are called application centric.
• Level of Authoritativeness
• Source of Structure
• Degree of Formality
• Model Dynamics
• Instance Dynamics
Highly authoritative ontologies are typically part of the institutional fabric of the organizations that will use them. If the
conceptualization is complex, it often pays to develop the specification in great depth. But if the authority of the
responsible institution is limited, the specification will generally have sharp boundaries and may be relatively narrow.
Ontologies that are not authoritative tend to be broad, since the creator can pick the most accessible concepts from many
conceptualizations, and generally not very deep. Such ontologies may not be reliable from a user perspective, so may not
attract sufficient resources to be developed in detail.
SNOMED1 is a very large and authoritative ontology. The periodic table of the elements is very authoritative, but small.
However, it can be safely used as a component of larger ontologies in physics or chemistry. Ontologies used for
demonstration or pedagogic purposes, like the Wine Ontology2, are not very authoritative. Table 7.1 can be seen as an
ontology which at present is not very authoritative. Should the classifications gain wide use in the ontology community,
the ontology in Table 7.1 would become more authoritative.
An ontology describes a structure that may be implemented in software of some kind. In some cases, the structure
represents published rules of engagement, required for interoperability, that can only be revised by authorized agents in a
well-publicized manner. In other words, the ontology is developed externally to the applications that use it; and changes
are made systematically, through a published revision process. Such an ontology is called transcendent. SNOMED is a
transcendent ontology defined by the various governing bodies of medicine. E-commerce exchanges are generally
supported by transcendent ontologies.
1. http://www.snomed.org
2. http://www.w3.org/2001/sw/WebOnt/guide-src/wine.owl
Degree of formality refers to the level of formality of the specification of the conceptualization, ranging from highly
informal or taxonomic in nature, to semantic networks, that may include complex subclass/superclass relations but no
formal axiom expressions, to ontologies containing highly formal axioms that explicitly define concepts. SNOMED is
taxonomic, as is the Standard Industrial Classification system (SIC) used by the US Department of Labor Statistics, while
engineering ontologies like Gruber and Olsen (1994) are highly formal.
All ontologies have structure, which likely evolves over time. If the ontology is transcendent, its maintaining organization
may decide to make a change; for immanent ontologies, new patterns may emerge from the data. The question is, how
often does the structure change? One extreme in the model dynamics dimension is stable or read-only ontologies that
rarely change in structure. The Periodic Table is structurally stable, as are generally the rules of an engagement.
SNOMED is relatively stable, as is the SIC (the SIC is slowly being replaced by the North American Industry
Classification System (NAICS) after 60 years, due to changes in the American economy in that period).
The other extreme in model dynamics is ontologies whose structure is volatile, changing often. An ontology supporting
tax accounting in Australia would be volatile at the model level, since the system of taxation institutional facts can
change, sometimes quite radically, with any Budget.
An ontology often includes a system of classes and properties (the structure), populated by instances (the extents). As
with model dynamics, instance knowledge may be stable (read-only) or volatile. The Periodic Table is stable at the
instance level (i.e., particular elements) as well as the model level (e.g., noble gasses or rare earths). New elements are
possible but rarely discovered. On the other hand, an ontology supporting an e-commerce exchange is volatile at the
instance level but possibly not at the model level. Z39.50 based applications are very stable in their model dynamics, but
volatile in their instance dynamics. Libraries are continually turning over their collections.
• Application Changeability
• Coupling
• Integration Focus
• Lifecycle Usage
This dimension considers who decides when and how much change to make to an ontology. One extreme is when the
body responsible for the ontology has sole decision on change (internally focused). The SIC is internally focused. Change
is required because the structure of the US economy has changed over the years, but the Bureau of Labor Statistics
decides how and when change is introduced.
The other extreme is when changes to the ontology are mandated by outside agencies (externally focused). In the US,
ontologies in the finance industry were required to change by the Sarbanes-Oxley Act of 2002, and changes in ontologies
in many areas were mandated by the Patriot Act, passed shortly after the World Trade Center attacks in 2001. An
ontology on taxation matters managed by a trade association of accountants is subject to change as the relevant taxation
acts are changed by governments.
An ontology may be used in applications. The applications may be developed once, as for an e-commerce exchange
(static) with periodic updates. On the other extreme, applications may be constructed dynamically (dynamic), as in an
application that composes web services at run time.
7.2.2.3 Coupling
This dimension describes how closely coupled applications committed to shared ontologies are to each other. The
applications in an e-commerce exchange are tightly coupled, since they must interoperate at run time. At the other
extreme, applications using the Periodic Table or the Engineering Mathematics ontology may have nothing in common at
run time. They are loosely coupled, solely because they share a component.
Some ontologies specify the structure of interoperation but not content. Z39.50 exclusive of the use attribute sets is a
good example. The MPEG-21 multimedia framework is another example. It specifies the structure of multimedia objects
without regard for their content. This extreme is called application integration, because they can be used to link programs
together so that the output of one is a valid input for the other.
Other ontologies specify content structure. An ontology may specify the structure of a shared knowledge base, for
example, for use by agents that exchange information about shared objects. This extreme is called information
integration. Ontologies used for integration may be both application and information focused.
• Business Applications have transcendent source of structure, a high degree of formality and external control relative to
nearly all users.
• Engineering Applications have transcendent source of structure, but users control them primarily internally and they
are considered more authoritative.
Description Authoritative Structure Formality Model Instance Control Change Coupling Focus Life
Dynamics Dynamics Cycle
7.4.1 Run-time Least/Broad Transcendent Formal Read- Volatile External Static Tight Information Real
Interoperation Only Time
7.4.2 Application Most/Deep Transcendent Formal Read- Read- External Static Loose Application All
Generation Only Only
7.4.3 Ontology Middle/ Transcendent Semi- Read- Read- External Static Tight Information Real
Lifecycle Broad& Deep Formal/ Only Only Time
Formal
7.5.1 Emergent Broad & Immanent Informal Volatile Read- Internal Dynamic Flexible Information Real
Property Deep Only & Time
Discovery External
7.5.2 Exchange of Broad & Immanent Informal Volatile Read- Internal Dynamic Flexible Information Real
Complex Deep Only/ & Time
Data Sets Volatile External
7.6.1 Information Broad & Transcendent Semi- Read- Volatile Internal Evolving Tight Information Design
System Deep Formal / Only Time
Development Formal
7.6.2 Ontology Broad & Transcendent Semi- Volatile Volatile Internal Evolving Flexible ??? Design
Engineering Deep Formal / Time
Formal
• Whether or not there is a design time component to ontology development and usage.
• Whether or not the knowledge bases and information resources that implement the ontologies are modified at run time
(since the source of structure remains relatively unchanged in these cases, or the ontologies are only changed in a
highly controlled, limited manner).
These applications may require mediation middleware that leverages the ontologies and knowledge bases that implement
them, potentially on either side of the firewall – in next generation web services and electronic commerce architectures as
well as in other cross-organizational applications, for example:
• For semantically grounded information interoperability, supporting highly distributed, intra- and inter-organizational
environments with dynamic participation of potential community members (as when multiple emergency services
organizations come together to address a specific crisis) with diverse and often conflicting organizational goals.
• For semantically grounded discovery and composition of information and computing resources, including Web
services (applicable in business process integration and grid computing).
In electronic commerce exchange applications based on state-full protocols such as EDI or Z39.50, where there are
multiple players taking roles performing acts by sending and receiving messages whose content refers to a common
world.
In these cases, we envision a number of agents and/or applications interoperating with one another using fully specified
ontologies. Support for query interoperation across multiple, heterogeneous databases is considered a part of this scenario.
While the requirements for ontologies to support these kinds of applications are extensive, key features include:
• the ability to represent situational concepts, such as player/actor – role – action – object – state,
• the necessity for multiple representations and/or views of the same concepts and relations, and
• separation of concerns, such as separating the vocabularies and semantics relevant to particular interfaces, protocols,
processes, and services from the semantics of the domain.
• Service checking that messages commit to the ontology at run time. These communities can have thousands of
autonomous players, so that no player can trust any other to send messages properly committed to the ontology.
• Authoritative environments, with tighter coupling between resources and applications than in cases that are less
authoritative or involve broader domains, though likely on the “looser side” of the overall continuum.
• Ontologies shared among organizations are highly controlled from a standards perspective, but may be specialized by
the individual organizations that use them within agreed parameters.
• The ontologies themselves are likely to be deeper and narrower, with a high degree of formality in their definition,
focused on the specific domain of interest or concepts and perspectives related to those domains.
For example:
• Dynamic regulatory compliance and policy administration applications for security, logistics, manufacturing, financial
services, or other industries.
• Applications that support sharing clinical observation, test results, medical imagery, prescription and non-prescription
drug information (with resolution support for interaction), relevant insurance coverage information, and so forth across
clinical environments, enabling true continuity of patient care.
Requirements:
• The ontologies used by the applications may be fully specified where they interoperate with external organizations and
components, but not necessarily fully specified where the interaction is internal.
• Conceptual knowledge representing priorities and precedence operations, time and temporal relevance, bulk domains
where individuals don’t make sense, rich manufacturing processes, and other complex notions may be required,
depending on the domain and application requirements.
• maintenance, storage, and archiving of ontologies for legal, administrative, and historical purposes,
Ontological information will be included in a standard repository for management, storage, and archiving. This may be to
satisfy legal or operations requirements to maintain version histories.
These types of applications require that Knowledge Engineers interact with Subject Matter Experts to collect knowledge
to be captured. UML models provide a visual representation of ontologies facilitating interaction. The existence of meta-
data standards, such as XMI and ODM, will support the development of tools specifically for Quality Assurance
Engineers and Repository Librarians.
Requirements implications:
• Full life-cycle support will be needed to provide managed and controlled progression from analysis, through design,
implementation, test and deployment, continuing on through the supported systems maintenance period.
• Part of the lifecycle of ontologies must include collaboration with development teams and their tools, specifically in
this case configuration and requirements management tools. Ideally, any ontology management tool will also be
ontology aware.
• It will provide an inherent quality assurance capability by providing consistency checking and validation.
• Semantically grounded knowledge discovery and analysis (e.g., financial, market research, intelligence operations).
• Semantics assisted search of data stored in databases or content stored on the Web (e.g., using domain ontologies to
assist database search, using linguistic ontologies to assist Web content search).
• Conflict discovery and prediction in information resources for self-service and manned support operations (e.g.,
technology call center operations, clinical response centers, drug interaction).
What these have in common is that the ontology is typically not directly expressed in the data of interest, but represents
theories about the processes generating the data or emergent properties of the data. Requirements include representation
of the objects in the ontology as rules, predicates, queries, or patterns in the underlying primary data.
Here the ontology functions more like a rich type system. It would often be combined with ontologies of other kinds (for
example, an ontology of radiological images might be linked to SNOMED for medical records and insurance
reimbursement purposes).
Requirements include
• Multiple inheritance where each semantic dimension or facet can have complex structure.
• Tools to assemble and disassemble complex sets of scientific and multi-media data.
• Facilities for mapping ontologies to create a cross reference. These do not need to be at the same level of granularity.
For the purposes of information exchange, the lower levels of two ontologies may be mapped to a higher level
common abstraction of a third, creating a sort of index.
• Methodology and tooling, where an application actually composes various components and/or creates software to
implement a world that is described by one or more component ontologies.
• Semantic integration of heterogeneous data sources and applications (involving diverse types of data schema formats
and structures, applicable in information integration, data warehousing, and enterprise application integration).
In the case of model-based applications, extent-descriptive predicates are needed to provide enough meta-information to
exercise design options in the generated software (e.g., describing class size, probability of realization of optional
classes). An example paradigm might reflect how an SQL query optimizer uses system catalog information to generate a
query plan to satisfy the specification provided by an SQL query. Similar sorts of predicates are needed to represent
quality-type meta-attributes in semantic web type applications (comprehensiveness, authoritativeness, currency).
The ontologies are used throughout the enterprise system development life cycle process to augment and enhance the
target system as well as to support validation and maintenance. Such ontologies should be complementary to and augment
other UML modeling artifacts developed as part of the enterprise software development process. Knowledge engineering
requirements may include some ontology development for traditional domain, process, or service ontologies, but may also
include:
Key requirements for ontology development environments supporting such activities include:
• Collaborative development
• Concurrent access and ontology sharing capabilities, including configuration management and version control of
ontologies in conjunction with other software models and artifacts at the atomic level within a given ontology,
including deprecated and deleted ontology elements.
• Forward and reverse engineering of ontologies throughout all phases of the software development lifecycle.
• Interoperation with other tools in the software development environment; integrated development environments.
• Localization support
• Cross-language support (ontology languages as opposed to natural or software languages, such as generation of
ontologies in the RDF(S)/OWL family of description logics languages, or in the Knowledge Interchange Format (KIF)
where first or higher order logics are required).
• Support for ontology analysis, including deductive closure; ontology comparison, merging, alignment, and
transformation.
• Support for import/reverse engineering of RDBMS schemas, XML schemas and other semi-structured resources as a
basis for ontology development.
Requirement Section
Structural features
Support ontologies expressed in existing description logic, (e.g. OWL/DL) and higher 7.4.2
order logic languages (e.g., OWL Full and KIF), as well as emerging and new 7.5.1
formalisms. 7.6.2
Efficient mechanisms will be needed to represent large numbers of similar classes or 7.4.1
instances.
Generic content
Support physical world concepts, including time, space, bulk or mass nouns like ‘water,’ 7.4.2
and things that do not have identifiable instances.
Support object concepts that have multiple facets of representations, e.g., conceptual 7.4.1
versus representational classes.
Provide a basis for describing stateful representations, such as finite state automaton to 7.4.1
support an autonomous agent’s world representation.
Provide a basis for information systems process descriptions to support interoperability, 7.4.1
including such concepts as player, role, action, and object.
Other generic concepts supporting particular kinds of domains 7.4.2
Run-time tools
Tools to assemble and disassemble complex sets of scientific and multi-media data. 7.5.2
Design-time tools
Associated with each requirement are the usage scenario from which it mainly arises.
The ODM uses the design principles, such as modularity, layering, partitioning, extensibility and reuse, that are
articulated in the UML Infrastructure document [UML Infra].
8.1 Why Not Simply Use or Extend the UML 2.0 Metamodel?
An ontology is a conceptual model, and shares characteristics with more traditional data models. The UML Class
Diagram is a rich representation system, widely used, and well-supported with software tools. Why not simply use UML
for representing ontologies?
OWL concepts, particularly those of OWL DL, represent an implementation of a subset of traditional first order logic
called Description Logics (DL), and are largely focused on sets and mappings between sets in order to support efficient,
automated inference. UML class diagrams are also based in set semantics, but these semantics are not as complete;
additionally, in UML, not as much care is taken to ensure the semantics are followed sufficiently for the purposes of
automatic inference. This can potentially be rectified with OCL, which is part of UML 2.0. The issues can be categorized
by cases where UML is overly restrictive, not restrictive enough, or simply doesn’t provide the explicit construct
necessary. For example:
• UML disjointedness requires disjoint classes to have a common super-type, which is not the case in OWL (aside from
the fact that all OWL classes are ultimately subclasses of owl:Thing, and similarly that all classes in RDF Schema are
resources).
• To model set intersection in UML one might consider using multiple inheritance, but this still allows an instance of all
the super-classes to be omitted from the subclass.
The lack of reliable set semantics and model theory for UML prevents the use of automated reasoners on UML models.
Such a capability is important to applying Model Drive Architecture to systems integration. A reasoner can automatically
determine if two models are compatible, assuming they have a rigorous semantics and axioms are defined to relate
concepts in the various systems.
Another distinction is in the ability to fully specify individuals apart from classes, and for individuals to have properties
independently of any class they might be an instance of in OWL. In this regard, UML shows its software heritage, in which
it is not possible for an instance to exist without a class to define its structure, a characteristic that derives from classes
used as abstractions of memory layout. It is not hard to work around this using singleton classes as proposed in the
profile, but for methodologies that start with instances and derive classes from them, this is clutter obviously introduced
from a practice in which the reverse is the norm.
In OWL Full, it is also common to reify individuals as classes. OWL Full allows classes to have instances that are
themselves classes or properties; classes and properties can be the domains of other properties. Elements of an ontology
frequently cross meta-levels, and may represent the equivalent of multiple meta-levels depending on the domain,
application, usage model, and so forth. Ontologists frequently want to see a combination of these classes and individuals
on the same diagram, and find it unnatural if they cannot. Many software languages reify classes, but UML has been only
half-hearted in supporting this mechanism. One can also work around this, however, as shown in the profile. The four-
layer meta level architecture that UML resides in does not restrict class reification, even though it is often confused with
reification. Classes and instances can reside on a single level of the architecture, at least if UML is used to describe that
layer.
The above problems could potentially be addressed in a revision of UML. However, the RFP to which this specification
is responding did not call for that.
As an initial part of the ODM development process, the team determined that understanding the requirements for ontology
development using ODM metamodels was essential to establishing the ODM architecture and selecting an appropriate set
of languages to be incorporated in the specification. The results of this requirements analysis are summarized in Chapter
7. The set of languages represented, the architecture, and potential extensions currently envisioned developed as a direct
consequence of this effort. This includes the notion that organizations developing ontologies may need to leverage pre-
existing data and process models represented in UML, Entity-Relationship (ER), or another modeling language even if the
development effort itself is conducted using an ODM metamodel. For some possible extensions to better support certain
classes of vocabularies or ontologies, see Annex D.
A significant exception is immanent ontologies, whose structure is derived from the information being exchanged as
distinguished from transcendent ontologies, whose structure is provided a priori by schemas and the like. News feeds,
results of data mining, and intelligence applications are examples of immanent ontologies, while e-commerce exchanges,
engineering applications, and controlled vocabularies generally are transcendent. Immanent ontologies are represented by
at least collections of terms, but often also by some numeric representation of the relationship among terms: co-
occurrence matrices, conditional probabilities of co-occurrence, and eigenvectors of co-occurrence matrices, for example.
These kinds of applications have not attracted the development of standardized representation structures as have
transcendent ontologies. The ODM team considered that it was outside the scope of this specification to innovate in areas
such as immanent ontology development without existing standard representations.
Once such an exchange is operating, it may have thousands of members, each of which will have its own information
system performing a variety of tasks in addition to interoperating through the exchange. These systems are all
autonomous, and the exchange has no interest in how they generate and interpret the messages they use to interoperate so
long as they commit to the ontology. Let us assume that the various members have systems with data models in UML or
dialects of the ER model. A given member will need to subscribe to at least a fragment of the ontology and make sure its
internal data model conforms to the fragment. It would therefore be an advantage to be able to translate a fragment of the
ontology to UML or ER to facilitate the member making any changes to its internal operations necessary for it to commit
to the ontology. Alternatively, a member might have a large investment in UML and would like the development to
leverage UML experience and UML tools to make at least a first approximation to alignment with the OWL model.
It is extremely important for those leveraging existing artifacts for ontology development to understand that “what makes
a good object-oriented software component model” does not necessarily make a good ontology. Once a particular model
has been translated to OWL, for example, care needs to be taken to ensure that the resultant model will support the
desired assertions in a knowledge base. Significant restructuring is often required, in other words.
The ODM therefore needs to provide facilities for making relationships among instances of its metamodels, including
UML. There are two ways to accomplish this: UML profiles and mappings.
We have provided such profiles for the Topic Maps, RDFS, and OWL metamodels, as one of the primary goals that
emerged from our use case development work was to enable use of existing UML tools for ontology modeling. The
profiles provided in Chapter 14 and Chapter15 were designed specifically for use in UML 2.0 tools. A profile for
Common Logic is under consideration as an extension to this specification through the OMG’s RFC process, as potential
applications for its use in business semantics and production rules applications were identified late in the specification
development process.
8.3.3 Mappings
Working with multiple metamodels may require a model element by model element translation of model instances from
one metamodel to another. UML profiling provides some capability for users to leverage UML as a basis for ontology
development for a specific knowledge representation language, such as RDF or OWL, but not necessarily to facilitate
complete transformations across the set of representation paradigms included in the ODM metamodels. We therefore need
to specify mappings from one metamodel to another.
Translation between metamodels has the fundamental problem that there may not be a single and separate model element
in the target corresponding to each model element in the source (indeed, if the metamodels are not simply syntactic
variations, this would be the normal situation). We will call this situation structure loss. Some of the issues involved with
structure loss and what to do about it using one of the earlier QVT proposals are discussed in [MSDW].
An overview of the mapping strategy used in the ODM is illustrated in Chapter 9. Note that there are mappings from each
metamodel to and from OWL Full, except for Common Logic (CL) for which there is only a mapping from OWL Full. A
lossy, reverse mapping defined in QVT from CL to OWL, and bi-directional mappings between UML and CL are
planned, and may be added through an RFP/RFC process.
An argument for the infeasibility of normative mappings is presented in Annex E. In a nutshell, the mappings provided in
the ODM are very general. Due to the very different scope and structure of the systems metamodeled, mappings based
solely on the general structure of the languages will often lead to less than ideal choices for mapping some structures.
Any particular mapping project will have additional constraints arising from the structure of the particular models to be
mapped and the purposes of the project, so will very likely make different mapping choices than those provided in the
ODM. An industry of consultants will likely arise, adding value by exactly this activity. They can use the ODM mappings
as a takeoff point, and as an aid to understanding the comparative model structure, so the ODM mappings have value as
informative, but not as normative.
The short answer to that question is that the ODM does include OCL in the same way it includes UML. Unfortunately,
just as UML lacks a formal model theoretic semantics, OCL also has neither a formal model theory nor a formal proof
theory, and thus cannot be used for automated reasoning (today). Common Logic, on the other hand, has both, and
therefore can be used either as an expression language for ontology definition or as an ontology development language in
its own right.
CL represents work that has been ongoing in the knowledge representation and logic community for a number of years. It
is a second-generation language intended to have an extremely concise kernel for efficient reasoning, has a surface syntax
for use with Semantic Web applications, and is rooted in the Knowledge Interchange Format (KIF Reference Manual v3.0
was published in 1992) as well as in other knowledge representation formalisms. It has also reached final committee draft
status (24707) in JTC 1 / SC32 of the ISO/IEC standards community, and should be finalized by the end of 2006.
Our original work with regard to the metamodel was done with active participation of the CL language authors, and
sought to be true to the abstract syntax of the CL language to the extent possible. Our intent was to enable ontologies
developed using the ODM to be operated on by DL and CL reasoners downstream. There are a number of such reasoners
Finally, given that the ODM includes mappings among the metamodels for the modeling languages, why not include
mappings between OCL and CL? Such a mapping should in principle be possible, but both languages are very rich. A
mapping between them must deal with concerns about issues related to unintended semantics, the ability to write complex
expressions involving multiple variables that preserve quantifier scope, and so forth. These issues are very important from
a reasoning perspective, and thus our approach needs to be well developed and tested using both OCL and CL reasoners
if we are to go down that path. This represents a longer term activity that may be taken up in the Ontology PSIG if there
is sufficient commercial interest in doing so.
• The advantage of using EMOF is that the modeling tools available during ODM development, such as IBM Rational
Rose, support EMOF (or close to it) but not CMOF. It was therefore possible to use such tools to define ODM meta-
models. At present, the newness of CMOF means that CMOF facilities are not supported by most tools. Therefore use
of CMOF facilities imposes a significant burden.
• The ODM metamodels can be represented in EMOF without sacrificing major syntactic or semantic considerations.
On the other hand, some of the possible extensions discussed in Annex D do require CMOF facilities. Use of EMOF in
the development of the ODM does not preclude extensions to CMOF as might be advantageous, and as the tools evolve
to support it.
8.6 M1 Issues
The ODM team encountered some issues in developing MOF-based metamodels for the W3C languages RDF, RDFS and
OWL, and to a lesser extent the ISO language Topic Maps. A MOF-based metamodel has a strict separation of meta-
levels. The number and designation of meta-levels is changed in MOF2 from MOF 1.4, but the issue can be described in
the MOF 1.4 designations:
• M3 – the MOF
• M2 – a MOF class model, specifying the classes and associations of the system being modeled, the structure of OWL,
for example.
• M1 – an instance of an M2 model, describing a particular instance of the system being modeled, a particular OWL
ontology, for example.
• M0 – ground individuals. A population of instances of the classes in a particular OWL ontology, for example.
RDFS and OWL are defined as specializations of RDF. RDF has natively a very simple model. There are resources and
properties. The entire structure of RDF, RDFS, and OWL is defined in terms of instances of resources, properties, and
other structures like classes, which are defined in terms of built-in resources and properties. In fact, even property is
formally defined as an instance of resource, and resource (the set of resources) is itself an instance of resource. These
languages are self-referential in a way that a native MOF metamodel could never be.
The Topic Maps metamodel in the ODM deals with the M1 problem by having an M2 structure following the published
Topic Map Data Model, with a note detailing the built-in M1 published subjects, but this approach does not suit the W3C
languages. In the ODM we have modeled RDF, RDF Schema, and OWL at the M2 level, following the published abstract
syntax for them. Certain built-in RDF/S and OWL constructs have relevance at multiple MOF meta-levels. Some of these,
such as annotation properties including rdfs:seeAlso, are included as M2 elements in the RDFS Metamodel; others, such
as ontology properties including owl:priorVersion, are included as M2 elements in the OWL Metamodel.
Some important constructs, however, are not appropriate to model at all at the M2 level. These are provided in an
ontology as an M1 model library (given in Annex A), and include:
• The built-in rdf:value property, suggested for use with structured values but not recommended for use by ODM team
members
• The set of XML Schema datatypes that are supported in RDF/S and OWL - xsd:string, xsd:boolean,
xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth,
xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:hexBinary, xsd:base64Binary,
xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN, xsd:Name,
xsd:NCName, xsd:integer, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int,
xsd:short, xsd:byte, xsd:nonNegativeInteger, xsd:unsignedLong, xsd:unsignedInt,
xsd:unsignedShort, xsd:unsignedByte and xsd:positiveInteger
• Additional RDF/S and OWL constructs that may have counterparts in the M2 metamodels (e.g., annotation properties
such as rdfs:label and rdfs:comment)
As introduced briefly in the RFP [ODM RFP], ontology is a discipline rooted in philosophy and formal logic, introduced
by the Artificial Intelligence community in the 1980s to describe real world concepts that are independent of specific
applications. Over the past two decades, knowledge representation methodologies and technologies have subsequently
been used in other branches of computing where there is a need to represent and share contextual knowledge
independently of applications.
An ontology defines the common terms and concepts (meaning) used to describe and represent an area of knowl-
edge. An ontology can range in expressivity from a Taxonomy (knowledge with minimal hierarchy or a parent/child
structure), to a Thesaurus (words and synonyms), to a Conceptual Model (with more complex knowledge), to a
Logical Theory (with very rich, complex, consistent, and meaningful knowledge).
This definition, and the analysis presented in Chapter 7, led to the determination that the ODM would ultimately include
six metamodels (four that are normative, and two that are informative). These are grouped logically together according to
the nature of the representation formalism that each represents: formal first order and description logics, structural and
subsumption / descriptive representations, and traditional conceptual or object-oriented software modeling.
At the core are two metamodels that represent formal logic languages: DL (Description Logics, which, although it is non-
normative, is included as informative for those unfamiliar with description logics, [BCMNP]) and CL (Common Logic),
a declarative first-order predicate language. While the heritage of these languages is distinct, together they cover a broad
range of representations that lie on a continuum ranging from higher order, modal, probabilistic, and intentional
representations to very simple taxonomic expression.
There are three metamodels that represent more structural or descriptive representations that are somewhat less expressive
in nature than CL and some DLs. These include metamodels of the abstract syntax for RDFS [RDF Schema], OWL
[OWL Reference]; [OWL S&AS], and TM (Topic Maps, [TMDM]). RDFS, OWL, and TM are commonly used in the
semantic web community for describing vocabularies, ontologies, and topics, respectively.
Two additional metamodels considered essential to the ODM represent more traditional, software engineering approaches
to conceptual modeling: UML2 [UML2], [UML Infra], and ER (Entity Relationship) diagramming. UML and ER
methodologies are arguably the two most widely used modeling languages in software engineering today, particularly for
conceptual or logical modeling. Interoperability with and use of intellectual capital developed in these languages as a
basis for ontology development and further refinement is a key goal of the ODM. Since UML2 is an adopted OMG
standard, we simply reference it in the ODM, and provide an additional non-normative mechanism for handling keys from
an ER perspective in Annex B. We anticipate a full metamodel for ER diagramming will be provided in the upcoming
Information Modeling and Management specification, the follow-on to the current Common Warehouse Metamodel
(CWM), and that there will be a mapping developed from the ODM to this new ER metamodel when it becomes
available.
Three UML profiles have been identified for use with the ODM for RDF, OWL, and Topic Maps. These enable the use of
UML notation (and tools) for ontology modeling and facilitate generation of corresponding ontology descriptions in RDF,
OWL, and TM, respectively.
CL is an exception to this strategy. CL is much more expressive than the other metamodels, and is therefore much more
difficult to map into the other metamodels. CL can be used to define constraints and predicates that cannot be expressed
(or are difficult to express) in the other metamodels. Some predicates might be specified in a primary metamodel, for
example, in OWL, and refined or further constrained in CL. The relevant elements of the M1 model expressed in the
primary metamodel will be mapped into CL. Thus, uni-directional mappings (to CL) only are included or planned at this
time.
Figure 9.1 shows the organization of the metamodels the relationships between the RDF and OWL packages.
<<metamodel>> <<metamodel>>
RDFBase <<merge>> RDFWeb
(from RDF) (from RDF)
<<merge>> <<merge>>
<<metamodel>>
OWL
(from org.omg.odm)
<<metamodel>>
OWLBase
(from OWL)
<<merge>> <<merge>>
<<metamodel>> <<metamodel>>
OWLDL OWLFull
(from OWL) (from OWL)
10.1 Overview
The Resource Description Framework (RDF) is a language standardized by the World Wide Web Consortium for
representing information (metaknowledge) about resources in the World Wide Web. It builds on a number of existing
W3C standards (including XML, URI, and related specifications), and provides a standardized way of defining
vocabularies for the Web that have an underlying formal model theoretic semantics, sufficient to support automated
reasoning if so desired.
10.1.1 Organization
The set of specifications that define RDF are divided into several components: basic concepts and abstract syntax, RDF
Schema that provides additional vocabulary development capabilities building on RDF, and a number of concrete syntax
variations, notably N3 and RDF/XML.
The RDF, RDF Schema (RDFS), RDFBase, and RDFWeb metamodels, defined herein, are MOF2 compliant metamodels
that allow a user to define RDF vocabularies using the terminology and concepts defined in the RDF specifications.
At the core, the RDFBase package reflects core concepts required by virtually all RDF applications, roughly, the set of
concepts defined in the RDF Concepts and Abstract Syntax specification [RDF Concepts].
The RDFS metamodel includes the concepts defined in the RDFBase package, and extends them to support the
vocabulary language defined in the RDF Schema specification [RDF Schema].
Finally, the RDFWeb package includes additional concepts that are not specific to RDF, but that define web document
content, specified in other W3C standards, and are required for complete representation of any concrete serialization of
RDF, including RDF/XML [RDF Syntax]. They are also necessary to support interoperability with other metamodels of
the ODM as well as with other external languages and applications.
Figure 10.1 provides an overview of the package structure. Note that the RDFBase package is part of the broader RDFS
package, but that RDFWeb is external to both, such that vendors choosing to support RDFBase without RDFS can
leverage the syntactic definitions from RDFWeb as needed.
RDF classes are represented by MOF classes. RDF properties are represented either by MOF classes or associations, as
appropriate.
RDF properties are first-class entities with unique identifiers. In addition, an RDF property can be a subproperty of
another RDF property. MOF associations, on the other hand, are not first-class entities. They are defined between two
MOF classes and their role names are locally scoped. In addition, in EMOF, a MOF association cannot be a sub
association of another MOF association, which exemplifies an inherent impedance mismatch between RDF Schema and
EMOF. Naming conventions, constraints in OCL, and textual description are used to overcome this impedance mismatch.
One issue that the authors were not able to work around is lack of support for multiple classification in MOF. This is
manifested in the RDFBase package in the definition of BlankNode. Blank nodes may have optional, local identifiers in
RDF, which are represented as a property called nodeID. BlankNode, URIReferenceNode, and RDFSLiteral form a
complete subclass partition of RDFSResource. In some cases, such as when defining anonymous classes in OWL, one
may need to know both the nodeID and identity in terms of the class description of the anonymous node. The nodeID may
not be available, however, due to lack of accessibility to BlankNode via MOF reflection. A work-around for this problem
is provided in Annex F.
10.1.2.2 Naming
Classes and properties defined in the RDF metamodel(s) have prefixed names derived from the way RDF and RDFS
namespaces are partitioned. One notable exception is RDFGraph, which does not have an explicit equivalent in the RDF
specifications but is differentiated for the sake of clarity with respect to the OWL metamodel.
Several RDF language co-authors shared that the distinction between the RDF and RDFS namespaces has become less
important and blurred over time, which has caused confusion in the Semantic Web community and created challenges for
metamodeling. Distinguishing between the RDFBase and RDFS packages along namespace boundaries was impossible
In addition, names of MOF classes are package qualified rather than globally scoped, as is the case with conventional
XML uniform resource identifiers (URIs). In fact, rdfs:Class, rdf:Property, and other names specified in the RDF
specifications are actually abbreviations for URIs using conventional namespace prefixes and concatenation. To make
matters worse, names of MOF association roles are local to the MOF classes where they are defined. The prefix
convention we have adopted assists in overcoming this impedance mismatch. For example, RDFSClass represents
rdfs:Class and RDFProperty represents rdf:Property. Concepts that are not explicitly part of the concrete
vocabulary of RDF/S, aside from RDFGraph, are not prefixed in this manner.
RDF provides a reification vocabulary for making statements about triples. This is described in Section 10.4 RDFBase
Package, RDF Statements.
10.2.1 BlankNode
Description
A blank node is a node that is not a URI reference or a literal. In the RDF abstract syntax, a blank node is simply a unique
node that can be used in one or more RDF statements, but has no intrinsic name.
Attributes
• nodeID: String [0..1] - the optional blank node identifier.
Associations
• uriRef: URIReference [0] in derived association URIRefForResource - the URI reference(s) associated with a
resource.
Constraints
[1] The multiplicity on the derived URIRefForResource association on the uriRef role must be 0 for BlankNodes.
Semantics
RDF makes no reference to the internal structure of blank nodes. The methodology for making such a determination is
left to the applications that use them, for example, through reasoning about them.
Blank nodes are treated as simply indicating the existence of a thing, without using or saying anything about the name of
that thing. (This is not the same as assuming that the blank node indicates an ‘unknown’ URI reference; for example, it
does not assume that there is any URI reference that refers to the thing.) Thus, they are essentially treated as existentially
quantified variables in the graph in which they occur, and have the scope of the entire graph. More on the semantics of
blank nodes is given in [RDF Semantics].
10.2.2 Node
Description
The subject and object of a Triple are of type Node. URIReferenceNode, BlankNode, and RDFSLiteral form a complete and
disjoint covering of Node.
Attributes
None
Associations
• tripleWithSubject: Triple [0..*] in association SubjectForTriple - the triple for which this node is a subject.
• tripleWithObject: Triple [0..*] in association ObjectForTriple - the triple for which this node is an object.
Constraints
[1] The set of blank nodes, the set of all RDF URI references (i.e., URIReferenceNodes) and the set of all literals
are pairwise disjoint.
Semantics
10.2.3 RDFProperty
Description
The RDF Concepts and Abstract Syntax specification [RDF Concepts] describes the concept of an RDF property as a
relation between subject resources and object resources. Every property is associated with a set of instances, called the
property extension. Instances of properties are pairs of RDF resources.
Attributes
None
Associations
Constraints
[1] The predicate of an RDF triple is a URI Reference (thus, a resource that is an RDF property, when used as the
predicate of a triple, must have a URI reference).
context RDFProperty HasURI inv:
self.uriRef->notEmpty
Semantics
A property relates resources to resources or literals. A property can be declared with or without specifying its domain
(i.e., classes which the property can apply to) or range (i.e., classes or datatypes that the property may have value(s)
from). This type represents the arc in RDF graphs.
10.2.4 RDFSLiteral
Description
Literals are used to identify values such as numbers and dates by means of a lexical representation. Anything represented
by a literal could also be represented by a URI, but it is often more convenient or intuitive to use literals.
• A plain literal is a string combined with an optional language tag. This may be used for plain text in a natural language.
Attributes
• uriRef: URIReference [0] in derived association URIRefForResource - the URI reference(s) associated with a
resource.
Associations
Constraints
[1] The multiplicity on the derived URIRefForResource association on the uriRef role must be 0 for literals.
[2] PlainLiteral and TypedLiteral are disjoint and form a complete covering of RDFSLiteral.
context RDFSLiteral inv DisjointPartition:
(self.oclIsKindOf(PlainLiteral) xor self.oclIsKindOf(TypedLiteral))
Semantics
Plain literals are self-denoting. Typed literals denote the member of the identified datatype’s value space obtained by
applying the lexical-to-value mapping to the literal string.
10.2.5 RDFSResource
Description
All things described by RDF are called resources. This is the class of everything. All other classes are subclasses of this
class.
Attributes
None
Associations
• uriRef: URIReference [0..*] in association URIRefForResource - the URI reference(s) associated with a resource.
Constraints
None
Semantics
The uriRef property is used to uniquely identify an RDF resource globally. Note that this property has a multiplicity of
[0..*] that provides for the possibility of the absence of an identifier, as in the case of blank nodes and literals. A
particular resource may be identified by more than one URI reference.
An RDF triple is conventionally written in the order subject, predicate, object. The relationship represented by the
predicate is also known as the property of the triple. The direction of the arc is significant: it always points toward the
object.
Attributes
None
Associations
• RDFsubject: Node [1] in association SubjectForTriple - links a triple to the node that is the subject of the triple.
• RDFpredicate: RDFProperty [1] in association PredicateForTriple - links a triple to the property that is the predicate of
the triple.
• RDFobject: Node [1] in association ObjectForTriple - links a triple to the node that is the object of the triple.
Constraints
[1] The resource (node) representing an RDFsubject can be a URI reference or a blank node but not a literal.
context Triple SubjectNotALiteral inv:
not self.RDFsubject.oclIsKindOf(RDFSLiteral)
[2] An RDFpredicate must be a URI reference (i.e., must not be a literal or blank node).
context Triple PredicateNotALiteral inv:
not self.RDFpredicate.oclIsKindOf(RDFSLiteral)
context RDFStatement PredicateNotABlankNode inv:
not self.RDFpredicate.oclIsKindOf(BlankNode)
Note: Both of these constraints are subject to change (may be relaxed) based on user experience in the Semantic Web
community. However, in any case, the constraint that a predicate must not be a literal is likely to remain.
Semantics
Each triple represents a statement of a relationship between the things denoted by the nodes that it links. The assertion of
an RDF triple says that some relationship, indicated by the predicate, holds between the things denoted by subject and
object of the triple.
10.2.7 UniformResourceIdentifier
Description
The RDF abstract syntax is concerned primarily with URI references. The definition of a URI, distinct from URI
reference, is included for mapping purposes. See [RDF Syntax] for definition details.
Associations
• uriRef: URIReference [0..*] in association URIForURIReference - zero or more URI references associated with the
URI.
Constraints
URIs must conform to the character encoding (including escape sequences and so forth) defined in [RDF Syntax] and are
globally defined. This is in contrast to naming and namespace conventions in UML2, which can be limited to the package
level or to a set of nested namespaces. While it may not be possible to define constraints on character strings in OCL to
enforce this, tools that implement this metamodel will be expected to support the W3C standards and related RFCs in this
regard.
Semantics
None
10.2.8 URIReference
Description
RDF uses URI references to identify resources and properties. A URI reference within an RDF graph (an RDF URI
reference) is a Unicode string conforming to the characteristics defined in [RDF Concepts] and [RDF Syntax].
• given as XML attribute values interpreted as relative URI references that are resolved against the in-scope base URI to
give absolute RDF URI references.
More on URI references and transformations from QNames is given in the discussion in Section 10.9 and in [RDF
Syntax].
Attributes
None
Associations
Semantics
Two RDF URI references are equal if and only if they compare as equal, character by character, as Unicode strings.
10.2.9 URIReferenceNode
Description
A URI reference or literal used as a node identifies what that node represents. URIReferenceNode is included in order to
more precisely model the intended semantics in UML (i.e., not all URI references are nodes). A URI reference used as a
predicate identifies a relationship between the things represented by the nodes it connects. A predicate URI reference may
also be a node in the graph.
Attributes
None
Associations
• uriRef: URIReference [1..*] in derived association URIRefForResource - the URI reference(s) associated with a
resource.
Constraints
[1] URIReferenceNode must inherit a URI from RDFSResource. In other words, the minimum multiplicity on the
derived URIRefForResource association on the uriRef role must be 1 for URIReferenceNodes.
context URIReferenceNode HasURI inv:
self.uriRef->notEmpty
Semantics
No additional semantics
0..1 0..1
+comment edResource +labeledResource
CommentForResource LabelForResource
+RDFScomment +RDFSlabel
0..* 0..*
PlainLiteral TypedLiteral
language : String [0..1]
0..1
+literal
DatatypeForTypedLiteral
+datatypeURI
1
RDFXMLLiteral URI Reference
10.3.1 PlainLiteral
Description
A plain literal is a string combined with an optional language tag. This may be used for plain text in a natural language.
Attributes
Associations
• labeledResource: RDFSResource [1] in association LabelForResource - links a human readable label with a resource.
Constraints
No additional constraints
Semantics
As recommended in the RDF formal semantics [RDF Semantics], plain literals are self-denoting.
• RDFSlabel: PlainLiteral [0..*] in association LabelForResource - links a resource to a human-readable name for that
resource.
The class rdf:XMLLiteral is the class of XML literal values. It is an instance of RDFSDatatype and a subclass of
TypedLiteral.
Attributes
None
Associations
Constraints
[1] The datatype name associated with an RDFXMLLiteral must refer to rdf:XMLLiteral.
Semantics
RDFXMLLiteral is a predefined RDF datatype used specifically for encoding XML in an RDF document. See [RDF
Concepts] for additional details.
10.3.4 TypedLiteral
Description
Typed literals have a lexical form, which is a Unicode string, and a datatype URI being an RDF URI reference.
Attributes
None
Associations
• datatypeURI: URIReference [1] in association DatatypeForTypedLiteral - the link between the typed literal and the
RDFSDatatype that defines its type (of which it is an instance), specifying the URI for the datatype specification.
Constraints
[1] A typed literal must have a datatype URI.
Semantics
The datatype URI refers to a datatype. For XML Schema built-in datatypes, URIs such as http://www.w3.org/2001/
XMLSchema#int are used. The URI of the datatype rdf:XMLLiteral may be used. There may be other, implementation
dependent, mechanisms by which URIs refer to datatypes.
The value associated with a typed literal is found by applying the lexical-to-value mapping associated with the datatype
URI to the lexical form. If the lexical form is not in the lexical space of the datatype associated with the datatype URI,
then no literal value can be associated with the typed literal. Such a case, while in error, is not syntactically ill formed.
• statementWithObject: RDFStatement [0..*] in association RDFObject - a resource represents an object of zero or more
RDF statements.
10.4.3 RDFStatement
Description
RDF Statement provides a way to make statements about triples or describe statements without asserting them.
Attributes
None
• RDFobject :RDFSResource [1] in association RDFObject - links a statement to the resource that is its object.
• RDFpredicate: RDFSProperty [1] in association RDFPredicate - links a statement to a property that is its predicate.
• RDFsubject: RDFSResource [1] in association RDFSubject - links a statement to a resource that is its subject.
• triple: Triple [0..1] in association ReificationForTriple - links a statement to the triple it reifies, if such a triple exists.
Constraints
None
Semantics
None
• statement: RDFStatement [0..1] in association ReificationForTriple - the statement that reifies the triple, if such a
statement exists.
10.5.1 NamedGraph
Description
A named graph is a uri reference and RDF graph pair. It effectively provides a way to name an RDF graph and thus refer to the
graph in a graph.
At the time of this writing, NamedGraphs are not a part of RDF, but have been proposed as a way of associating metadata with
semantic web content that can be used to handle issues of trust and access, among other things. A named graph construct is
Attributes
None
Associations
• graphForNG: RDFGraph [1] in association GraphForNamedGraph - a named graph is associated with exactly one
RDF graph.
• subGraphOf: NamedGraph [0..*] in association SubGraphOf - links a named graph with named graphs for which it is a
subgraph.
• RDFGequivalentGraph: NamedGraph[0..*] in association EquivalentGraph - links a named graph with named graphs
that are equivalent.
Constraints
[1] The multiplicity on the derived URIRefForResource association on the uriRef role must be 1 for
NamedGraphs.
Semantics
A named graph is a first class object that represents an RDF graph. It is named with a URIReference. Two relationship types
are predefined for relationships among named graphs (EquivalentGraph and SubGraphOf). These assert equivalence and
subset relationships respectively among the RDF graphs (in the graphForNG role) that correspond to the named graphs linked
by these relationships.
10.5.2 RDFGraph
Description
An RDF graph is a set of RDF triples. The set of nodes of an RDF graph is the set of subjects and objects of triples in the
graph.
A number of classes in the metamodel, including RDFGraph, RDFStatement, Document, etc., are included (1) for the
sake of completeness, and (2) are provided for vendors to use, as needed from an application perspective. They may not
be necessary for all tools, and may not necessarily be accessible to end users, again, depending on the application
requirements.
Attributes
None
Associations
• namedGraph: NamedGraph [0..*] in association GraphForNamedGraph - links an RDF graph with named graphs that
may represent it.
3. http://www2005.org/cdrom/docs/p613.pdf
Constraints
None
Semantics
As described in [RDF Semantics], RDF is an assertional language, intended for use in defining formal vocabularies and
using them to state facts and axioms about some domain.
An RDF graph is defined as a set of RDF triples. A subgraph of an RDF graph is a subset of the triples in the graph. A
triple is identified with the singleton set containing it, so that each triple in a graph is considered to be a subgraph. A
proper subgraph is a proper subset of the triples in the graph. A ground RDF graph is one with no blank nodes.
The assertion of an RDF triple says that some relationship, indicated by the predicate, holds between the things denoted
by subject and object of the triple. The assertion of an RDF graph amounts to asserting all the triples in it, so the meaning
of an RDF graph is the conjunction (logical AND) of the statements corresponding to all the triples it contains.
• graph: RDFGraph [1..*] in association TripleForGraph - the graph(s) containing the triple.
RDFS distinguishes between a class and the set of its instances. Associated with each class is a set, called the class
extension of the class, which is the set of the instances of the class. Two classes may have the same set of instances but
be different classes. A class may be a member of its own class extension and may be an instance of itself. This feature of
RDF Schema (and, as a result, of OWL) may be unintuitive for a traditional UML user, and makes distinguishing
metalevels in an ontology challenging.
TypeForResource
+RDFt ype
+RDFSsubClassOf 1..*
0..* RDFSClass RDFSDatatype
ClassGeneralization 0..*
+superClassOf
10.6.1 RDFSClass
Description
The group of resources that are RDF Schema classes is itself a class, called rdfs:Class. Classes provide an abstraction
mechanism for grouping resources with similar characteristics.
If a class C is a subclass of a class C', then all instances of C will also be instances of C'. The rdfs:subClassOf
property may be used to state that one class is a subclass of another. The term superClassOf is used as the inverse of
rdfs:subClassOf. If a class C' is a superclass of a class C, then all instances of C are also instances of C'.
Attributes
None
Associations
• RDFSsubClassOf: RDFSClass [0..*] in association ClassGeneralization - links a class to another class that generalizes
it.
• superClassOf: RDFSClass [0..*] in association ClassGeneralization - links a class to another class that specializes it
(note that superClassOf is not an RDF concept).
• typedResource: RDFSResource [0..*] in association TypeForResource - links a class to a resource that is an instance of
the class.
Constraints
None
10.6.2 RDFSDatatype
Description
Datatypes are used by RDF in the representation of values such as integers, floating point numbers and dates. A datatype
consists of a lexical space, a value space, and a lexical-to-value mapping.
RDF predefines just one datatype rdf:XMLLiteral, used for embedding XML in RDF. There are no built-in concepts
for numbers, dates, or other common values. Rather, RDF defers to datatypes that are defined separately and identified
with URI references. The predefined XML Schema Datatypes [XML Schema Datatypes] are expected to be used for this
purpose. Additionally, RDF provides no mechanism for defining new datatypes. XML Schema provides a framework
suitable for defining new datatypes for use in RDF.
rdfs:Datatype is the class of datatypes. All instances of rdfs:Datatype correspond to the RDF model of a datatype
described in the RDF Concepts specification [RDF Concepts] rdfs:Datatype is both an instance of and a subclass of
rdfs:Class. Each instance of rdfs:Datatype is a subclass of rdfs:Literal.
Attributes
None
Associations
• uriRef: URIReference [1..*] in derived association URIRefForResource - the URI reference(s) associated with a
resource.
Constraints
[1] RDFSDatatype classes must inherit URI references from RDFSResource.
context RDFSDatatype HasURI inv:
self.uriRef->notEmpty
[2] Each instance of RDFSDatatype is a subclass of TypedLiteral:
context RDFSDatatype InstancesAreLiterals inv:
self.instance->forall (instance | instance.oclIsKindOf(TypedLiteral ))
Semantics
RDF provides for the use of externally defined datatypes identified by a particular URI reference, but imposes minimal
conditions on datatype definitions. It includes a single built-in datatype, rdf:XMLLiteral.
The semantics given for datatype definitions are minimal. RDF makes no provision for associating a datatype with a
property so that it applies to all values of the property, and does not provide any way of explicitly asserting that a blank
node denotes a particular datatype value. Such features may be provided in the future, for example, more elaborate
datatyping conditions. Semantic extensions may also refer to other kinds of information about a datatype, such as
orderings of the value space.
A datatype is an entity characterized by a set of character strings called lexical forms and a mapping from that set to a set
of values. How these sets and mappings are defined is considered external to RDF.
• a mapping from the lexical space of d to the value space of d, called the lexical-to-value mapping of d.
The set of datatypes from [XML Schema Datatypes] available for use in RDF is limited to those with well defined
semantics, those that do not depend on enclosing XML documents (e.g., xsd:QName is excluded), those that are not used
for XML document cross-reference purposes, and so forth. The set of allowable datatypes is provided in Annex A.
Note that the multiplicity on RDFtype is [1..*], meaning that every resource must be typed. Yet, many resources in RDF
are not explicitly typed, so this may seem unintuitive from an RDF perspective. In essence, this says that every resource
is, at a minimum, of type rdfs:Resource (required from a metamodeling and mapping perspective to support
representation of RDF and OWL individuals without the addition of other artificial constructs). This does not, however,
necessarily mean that vendors should add the inferred triples automatically when generating RDF/S and/or OWL from a
model instance. This should only be done deliberately, depending on the application.
Associations
• definedResource: RDFSResource [0..*] in association DefinedByResource - relates a particular resource to other
resources that it defines.
• RDFSseeAlso: RDFSResource [0..*] in association SeeAlsoForResource - relates a resource to another resource that
may provide additional information about it.
• RDFtype: RDFSClass [1..*] in association TypeForResource - relates a resource to its type (i.e., states that the resource
is an instance of the class that is its type).
Constraints
[1] RDFSseeAlso and RDFSisDefinedBy must have non-empty URI references.
[2] RDFSisDefinedBy is a subPropertyOf RDFSseeAlso.
• datatypeURI: RDFSDatatype [1] in association DatatypeForTypedLiteral - the link between the typed literal and the
RDFSDatatype that defines its type (of which it is an instance), specifying the URI for the datatype specification (note
that because TypedLiteral is defined in RDFBase, the constraint requiring the URI reference to point to an instance of
RDFSDatatype is refined here).
RDF Schema defines the concept of subproperty. The rdfs:subPropertyOf property may be used to state that one property
is a subproperty of another. If a property P is a subproperty of property P', then all pairs of resources that are related by P
are also related by P'. The term super-property is often used as the inverse of subproperty. If a property P' is a super-
property of a property P, then all pairs of resources that are related by P are also related by P'.
RDF/RDFS does not define a top property that is the super-property of all properties. Such a definition may be included
in a model library if vendors so desire. The properties diagram is shown in Figure 10.7.
RDFSResource
(from RDFBase)
• RDFSdomain: RDFSClass [0..*] in association DomainForProperty - links a property to zero or more classes
representing the domain of that property. A triple of the form: P rdfs:domain C . states that P is an instance of the
class rdf:Property, that C is an instance of the class rdfs:Class and that the resources denoted by the subjects of
triples whose predicate is P are instances of the class C. Where a property P has more than one rdfs:domain
property, then the resources denoted by subjects of triples with predicate P are instances of all the classes stated by the
rdfs:domain properties.
• RDFSrange: RDFSClass [0..*] in association RangeForProperty - links a property to zero or more classes representing
the range of that property. A triple of the form: P rdfs:range C . states that P is an instance of the class
rdf:Property, that C is an instance of the class rdfs:Class and that the resources denoted by the objects of triples
whose predicate is P are instances of the class C. Where P has more than one rdfs:range property, then the resources
denoted by the objects of triples with predicate P are instances of all the classes stated by the rdfs:range properties.
• superPropertyOf: RDFProperty [0..*] in association PropertyGeneralization - links a property to another property that
specializes it (note that superPropertyOf is not an RDFS concept).
Semantics
Properties may be specialized. The existence of an instance of a specializing property implies the existence of an instance
of the specialized property, relating the same set of resources.
• propertyForDomain: RDFProperty [0..*] in association DomainForProperty - links a class to a property for which it is
the domain.
• propertyForRange: RDFProperty [0..*] in association RangeForProperty - links a class to a property for which it is the
range.
Figure 10.8 provides the metamodel elements defined to support RDF containers and collections.
RDFSContainer RDFProperty
(from RDFBas e)
Three different kinds of container are defined for different intended uses. An rdf:Bag is used to indicate that the
container is intended to be unordered. An rdf:Seq is used to indicate that the order indicated by the numerical order of
the container membership properties of the container is intended to be significant. An rdf:Alt container is used to
indicate that typical processing of the container will be to select one of the members.
This is the class of RDF “Alternative” containers. The rdf:Alt class is used conventionally to indicate to a human
reader that typical processing will be to select one of the members of the container. The first member of the container, i.e.,
the value of the rdf:_1 property, is the default choice.
Attributes
None
Associations
Constraints
None
Semantics
See discussion in [RDF Concepts] of container membership semantics. (Note that the blank nodes are intended to be
interpreted as existentially quantified variables representing instances of URIs in rdf:Property.)
10.8.2 RDFBag
Description
This is the class of RDF “Bag” containers. It is used conventionally to indicate that the container is intended to be
unordered.
Attributes
None
Associations
Constraints
None
Semantics
10.8.3 RDFList
Description
This class represents descriptions of RDF collections, conventionally called lists, and other list-like structures.
No additional attributes
Associations
• originalList: RDFList [0..*] in association RestOfList - the original list for rdf:rest.
• RDFfirst: RDFSResource [0..1] in association FirstElementInList - links a list to its first element.
• RDFrest: RDFList [0..1] in association RestOfList - links a list to its sublist excluding its first element.
• Specialize Class RDFSResource.
Constraints
None
Semantics
rdf:Nil is a predefined instance of rdf:List that explicitly denotes the termination of an rdf:List. Since rdf:Nil
is at the model level, it is not explicitly represented, outside of the model library provided in Annex A.
10.8.4 RDFSContainer
Description
Attributes
None
Associations
Constraints
None
Semantics
The same resource may appear in a container more than once. A property of a container is not necessarily a property of
all of its members.
10.8.5 RDFSContainerMembershipProperty
Description
The rdfs:ContainerMembershipProperty class has as instances the properties rdf:_1, rdf:_2, rdf:_3 ... that are
used to state that a resource is a member of a container. Each instance of this class is an rdfs:subPropertyOf the
rdfs:memberOf property.
None
Associations
• Specialize Class RDFProperty
Constraints
None
Semantics
Container membership properties may be applied to resources other than containers. (Note that the blank nodes are
intended to be interpreted as existentially quantified variables representing instances of URIs in rdf:Property.) The
instances that make up this class are provided in the model library given in Annex A.
10.8.6 RDFSeq
Description
This is the class of RDF “Sequence” containers. It is used conventionally to indicate that the numerical ordering of the
container membership properties of the container is intended to be significant.
Attributes
None
Associations
Constraints
None
Semantics
• container: RDFSResource [0..*] in association MemberOfResource - relates a particular resource to other resources
that are its members.
• list: RDFList [0..*] in association FirstElementInList - relates a particular resource to the list(s) for which it is the
initial element.
Concepts including RDF document, namespaces, the definitions that map namespaces to namespace prefixes, and the
associations between a set of statements and the document that contains them facilitate the systematic exchange of these
definitions across modeling environments, and can be mapped to similar features in a Common Logic ontology, Topic
Map, UML, or ER conceptual model.
Figure 10.9 specifies several concepts that link an RDF document to the names and statements it contains. While both
documents and graphs may have sets of statements associated with them, namespace definitions, and the mappings
between namespace prefixes and URIs are associated with RDF documents (in this simplified view of XML Schema - in
actuality, they are associated with XML elements), not with RDF graphs.
Note that the model supports multiple graphs within a document, and the notion that a particular graph may cover
multiple documents. While in common practice there can be a one to one correspondence between a document and a
graph, examples of both kinds of exceptions are included in the set of RDF specifications defining the language and in
related W3C documents.
Single graph covering multiple documents. The ability to refer to definitions that are external to a particular document
(e.g., XML Schema Datatypes) and in OWL, the ability to directly import such definitions, naturally extends a graph
beyond the boundaries of a single document. Additionally, in [RDF Primer], there is a discussion of the use of XML Base,
such that relative URIs may be defined based on a base URI other than that of the document in which they occur. This
may be appropriate, for example, when there are mirror sites that share common definitions and extend them at the mirror
site, but where it is not necessary to duplicate all definitions at every such site. In such cases, a graph can span multiple
documents, and the URI of the mirror site document is distinct from that of its base. As a result, the metamodel provides
for the optional definition of an xml:base distinct from the URI of the document.
Multiple graphs in the same document. It is common practice in ontology development to have multiple “main nodes”
in the same document - for example, multiple concepts whose parent class is simply owl:Thing, or classes without a
defined “parent class” in RDF. Some explicit examples are provided in the discussion of Named Graphs (see http://
www.w3.org/2004/03/trix/, particularly those given on the TriG Homepage, at http://www.wiwiss.fu-berlin.de/suhl/bizer/
TriG/). One can imagine others such as when defining SKOS-based concept schemes, or thesauri, and managing multiple
versions of such schemes (see the SKOS Core Guide, http://www.w3.org/TR/swbp-skos-core-guide, and http://
www.w3.org/TR/swbp-thesaurus-pubguide, for more information). The ability to name a graph provides a means by
which multiple component graphs defined in the same document can be referenced externally as a unit, enabling graph
mapping and alignment, for example. Thus, the NamedGraph class can be used to support naming graphs for those
applications that require this feature. While the notion of a named graph is not yet part of the formal RDF W3C
recommendations, emerging work on SKOS vocabularies and SPARQL confirms that use of named graphs is becoming
increasingly important to applications, and is considered mainstream.
Bounding an RDF vocabulary. The notion of scope is somewhat opaque in the current set of recommendations that
together define RDF and its vocabulary language, RDF Schema. This is, in part, due to the fact that URIs have global
scope in RDF. Yet, we need a way of talking about and modeling the set of resources that describe a particular vocabulary.
Each document is associated with a resource whose URI reference is the primary URL where the document is published.
It is good practice to include this URL in the serialized form of an RDF XML document, as the value of an xml:base on
its root element. The bounds of a particular RDF vocabulary is the collection of statements (triples) sharing a base URI,
or, in the absence of such a URI, a graph whose base URI is, by default, that of the document that contains it.
Secondly, the rdf:ID attribute on a node element (not property element) can be used instead of rdf:about and gives a
relative RDF URI reference equivalent to # concatenated with the rdf:ID attribute value. So for example if
rdf:ID="name", that would be equivalent to rdf:about="#name". rdf:ID provides an additional check since the same
name can only appear once in the scope of an xml:base value (or document, if none is given), so is useful for defining
a set of distinct, related terms relative to the same RDF URI reference.
Both forms require a base URI to be known, either from an in-scope xml:base, or, in the case of a reference to a
definition outside of the current document, from the URI of the RDF/XML document in which the target definition is
specified.
RDF's conceptual model is a graph. RDF also provides an XML syntax for writing down and exchanging RDF graphs,
called RDF/XML. An RDF document is a serialization of an RDF graph into a concrete syntax, as specified in [RDF
Syntax], which provides the container for the graph, and conventionally also contains declarations of the XML
namespaces referenced by the statements in the document.
RDF refers to a set of URI references as a vocabulary. Often, the URI references in such vocabularies are organized so
that they can be represented as sets of QNames using common prefixes. URI references that are contained in the
vocabulary are formed by appending individual local names to the relevant prefix. This practice is also commonly used in
OWL ontology development for improved readability. While the metamodel does not explicitly support QNames, the
elements required to enable such support in vendor implementations are provided.
Attributes
None
Associations
• localName: LocalName [0..*] in association DocumentContainsLocalName - links a document to the set of local
names it contains.
• triple: Triple[1..*] in association TripleForDocument - links a document to the set of triples it contains.
• uriRef: URIReference [1..*] in derived association URIRefForResource - the URI reference(s) associated with a
resource.
• xmlBase: Namespace [0..*] in association DefaultNamespaceForDocument - links a document to one or more default
namespaces (xml:base namespaces) associated with the statements in the document.
Constraints
[1] A document must have a URI.
[2] Local names with URIs that match the URI of the document are contained by (local to) the document.
Semantics
An RDF/XML document is only required to be well-formed XML; it is not intended to be validated against an XML DTD
(or an XML Schema).
10.9.2 LocalName
Description
RDF uses an RDF URI Reference, which may include a fragment identifier, as a context free identifier for a resource. The
meaning of a fragment identifier depends on the MIME content-type of a document, i.e., is context dependent.
The typical practice is to split a URI reference into two parts such that the right is maximal being an NCName as
specified by XML Namespaces, which might best be implemented by vendors as a method on the model. Atypical (but
formally permitted) practice includes allowing multiple LocalNames for each URIReference, i.e., any split as above,
without the right part being maximal. Also note that some URIrefs (specifically those suggested for user defined
datatypes in XML Schema) cannot be split in this way, since they have no rightmost NCName.
The definitions provided in this metamodel are also sufficient to generate QNames: split each URI reference as above (or
using LocalName), look the first half up as a namespace, and then form a qname.
Attributes
• name: String [1] - the string representing the local name or fragment identifier.
Associations
• document: Document [1..1] in association DocumentContainsLocalName - links local names to the document that
contains them.
• uriRef: URIReference [0..*] in association FragmentIdentifierForURIRef - links the fragment identifier to zero or
more URIs that reference it.
Constraints
None
Semantics
None
10.9.3 Namespace
Description
An XML namespace is a collection of names, identified by a URI reference, which are used in XML documents as
element types and attribute names.
Attributes
None
Associations
• document: Document [1..*] in association NamespaceForDocument - the document(s) for which it is the default
namespace (or xml:base).
Constraints
[1] Namespaces should conform to the specification given in “[XMLNS]” on page 4. While it may not be possible
to define constraints on character strings in OCL to enforce this (and while the namespace recommendation
may not explicitly require enforcement), tools that implement this metamodel will be expected to support the
W3C standards and related RFCs to the extent possible.
Semantics
None
10.9.4 NamespaceDefinition
Description
A namespace is declared using a family of reserved attributes. These attributes, like any other XML attributes, may be
provided directly or by default. Some names in XML documents (constructs corresponding to the non-terminal Name)
may be given as qualified names. The prefix provides the namespace prefix part of the qualified name, and must be
associated with a namespace URI in a namespace declaration.
Namespace definitions are used in RDF and OWL for referencing and/or importing externally specified terms,
vocabularies, or ontologies.
Attributes
Associations
• document: Document [1] in association NamespaceDefinitionForDocument - the document(s) using the namespace
definition.
Constraints
[1] Namespace definitions should conform to the specification given in [XMLNS].
Semantics
None
• document: Document [1..*] in association TripleForDocument - the document(s) containing the triple.
Constraints
[1] A non-empty fragmentIdentifier associated with an empty uri implies that the uri is the xml:base (default
namespace) of the document.
11.1 Overview
The Web Ontology Language (OWL) is a semantic markup language for publishing and sharing ontologies on the World
Wide Web. Where earlier knowledge representation languages have been used to develop tools and ontologies for specific
user communities (particularly in the sciences and in company-specific e-commerce applications), they were not defined
to be compatible with the architecture of the World Wide Web in general, and the Semantic Web in particular.
OWL uses both URIs for naming and the description framework for the Web provided by RDF to add the following
capabilities to ontologies:
OWL builds on RDF and RDF Schema and augments the RDFS vocabulary for describing properties and classes: among
others, relations between classes (e.g., disjointedness), cardinality (e.g., “exactly one”), equality, richer typing of
properties, characteristics of properties (e.g., symmetry), and enumerated classes.
The OWL Metamodel is a MOF2 compliant metamodel that allows a user to specify ontologies using the terminology and
underlying model theoretic semantics of OWL [OWL S&AS]. The OWL Metamodel extends the set of metamodels
defined herein for RDFBase, RDFS (RDF Schema), and RDFWeb.
OWL provides three increasingly expressive sublanguages designed for use by specific communities of users and
implementors:
• OWL Lite - which supports users primarily needing a classification hierarchy and simple constraints.
• OWL DL - which supports users who want maximum expressiveness without losing computational completeness and
decidability of reasoning systems.
• OWL Full - which is intended for users who want maximum expressiveness and the syntactic freedom of RDF without
computational guarantees.
Based on requirements derived from the usage scenarios described in Chapter 7, Usage Scenarios and Goals, the ODM
was designed to enable ontology development using either OWL DL or OWL Full, which essentially share abstract syntax
constructs and differ primarily in terms of constraints. We have not explicitly covered OWL Lite, but all constructs and
many relevant constraints are provided in the base OWL and OWL DL packages. Vendors who are interested in
supporting OWL Lite can simply use the relevant constructs from the base package and tighten constraints from the OWL
DL package, as required.
As in the RDF metamodels, prefixes are used in naming MOF classes and MOF properties that directly represent OWL
classes and OWL properties, respectively. For example, OWLClass represents owl:Class and OWLimports represents
owl:imports. Individual, which does not have a prefix, represents something that is not explicitly defined in the RDF/
11.2.1 OWLGraph
Description
As defined in Chapter 10, an RDF graph is a set of RDF triples. The set of nodes of an RDF graph is the set of subjects
and objects of triples in the graph. Not all RDF graphs are valid OWL graphs, however. The OWLGraph class specifies
the subset of RDF graphs that are valid OWL graphs.
Attributes
None
• ontology: OWLOntology [0..*] in association GraphForOntology - relates zero or more ontologies to the graphs they
contain.
• triple: Triple [1..*] in association TripleForOntology (derived) - links an OWL graph to the set of triples it contains.
• Specialize Class RDFGraph.
Constraints
[1] If an OWL Triple t of OWLOntology o, identified through TripleForOntology, is linked through
TripleForGraph to an OWLGraph g, then that OWLGraph g must be linked with OWL Ontology o.
[2] If an OWLGraph g is linked with an OWLOntology o, then they must have a triple in common.
Semantics
No additional semantics
11.2.2 OWLOntology
Description
An OWL ontology contains a sequence of annotations, axioms, and facts. Annotations on OWL ontologies can be used to
record authorship and other information associated with an ontology, including imports references to other ontologies.
The main content of OWLOntology is carried in its axioms and facts, which provide information about classes, properties,
and individuals in the ontology.
Names of ontologies are used in the abstract syntax to carry the meaning associated with publishing an ontology on the
Web. The intent is that the name of an ontology in the abstract syntax is the URI where it can be found, although this is
not part of the formal meaning of OWL. Imports annotations, in effect, are directives to retrieve a Web document and
treat it as an OWL ontology.
Attributes
None
Associations
• owlGraph: OWLGraph [1..*] in association GraphForOntology - links an ontology to one or more graphs containing
the triples that define it.
• importingOntology: OWLOntology [0..*] in association Imports - links an ontology to zero or more other ontologies it
imports.
• OWLimports: OWLOntology [0..*] in association Imports - links an ontology to zero or more other ontologies it
imports.
• newerOntology: OWLOntology [0..*] in association PriorVersion - links an ontology to zero or more other ontologies
that are earlier versions of the current ontology.
• OWLpriorVersion: OWLOntology [0..*] in association PriorVersion - links an ontology to zero or more other
ontologies that are earlier versions of the current ontology.
• OWLversionInfo: RDFSLiteral [0..*] in association VersionInfo - links an ontology to an annotation providing version
information.
• triple: Triple [1..*] in association TripleForOntology - links an ontology to one or more triples it contains.
Constraints
[1] If an OWLOntology o is not named (i.e., does not inherit a URI reference from RDFSResource, and no
xmlBase namespace is specified), then its main node is a blank node when mapped to an OWLGraph g;
otherwise, its main node is the main node of the OWLGraph g corresponding to the URIReference u that names
it.
[2] If a Triple t of OWLOntology o, identified through TripleForOntology, is linked through TripleForGraph to an
OWLGraph g, then that OWLGraph g must be linked with OWLOntology o.
[3] If an OWLGraph g is linked with an OWLOntology o, then they must have a triple in common.
[4] If a Triple t is linked through TripleForGraph to an OWLGraph g of an OWLOntology o (identified through
GraphForOntology), then that Triple t must be in OWLOntology o.
Semantics
An owl:imports statement references another OWL ontology containing definitions, whose meaning is considered to be
part of the meaning of the importing ontology. Each reference consists of a URI specifying from where the ontology is to
be imported. Syntactically, owl:imports is a property with the class owl:Ontology as its domain and range.
The owl:imports statements are transitive, that is, if ontology A imports B, and B imports C, then A imports both B and
C. Importing an ontology into itself is considered a null action, so if ontology A imports B and B imports A, then they are
considered to be equivalent.
An owl:versionInfo statement generally has as its object a string giving information about this version, for example
RCS/CVS keywords. This statement does not contribute to the logical meaning of the ontology other than that given by
the RDF(S) model theory. Although this property is typically used to make statements about ontologies, it may be applied
to any OWL construct.
An owl:priorVersion statement contains a reference to another ontology. This identifies the specified ontology as a
prior version of the containing ontology. This has no meaning in the model-theoretic semantics other than that given by
the RDF(S) model theory. However, it may be used by software to organize ontologies by versions.
An owl:incompatibleWith statement contains a reference to another ontology. This indicates that the containing
ontology is a later version of the referenced ontology, but is not backward compatible with it. Essentially, this is for use
by ontology authors who want to be explicit that documents cannot upgrade to use the new version without checking
whether changes are required.
• ontology: OWLOntology [1] in association VersionInfo - links an owl:versionInfo annotation to the ontology it
describes.
• restrictionClass: HasValueRestriction [0..*] in association HasLiteralValue - optionally links one literal to a has value
property restriction.
• owlGraph: OWLGraph [1..*] in association TripleForGraph (derived) - links an OWL graph to the set of triples it
contains.
Constraints
[1] If an OWL Triple t is linked through TripleForGraph to an OWLGraph g of an OWLOntology o (identified
through GraphForOntology), then that Triple t must be in OWLOntology o.
A class description, as shown in Figure 11.3, describes an OWL class, either by a class name or by specifying the class
extension of an unnamed anonymous class. OWL distinguishes six types of class descriptions:
The first type is special in the sense that it describes a class through a class name (syntactically represented as a URI
reference). The other five types of class descriptions describe an anonymous class by placing constraints on the class
extension. Note that it is not required that these other five types of class descriptions be anonymous (unnamed), and for
convenience, reuse, and readability purposes, such naming is common.
RDFSClass
(from RDFS)
+OWLequivalentClass +OWLdisjointWith
EquivalentClass DisjointClass
+equivalentClass 0..* 0..*
+disjointClass
0..* OWLClass 0..*
isDeprecated : Boolean [ 0..1]
+OWLintersectionOf
+OWLcomplementOf
0..*
1
0..*
Int ersectionClassForInt ersection
+OWLunionOf
ComplementClassForComplement
UnionClassForUnion
+complementClass +unionClass
0..* 0..*
ComplementClass EnumeratedClass I ntersectionClass OWLRestriction UnionClass
0..* 0..*
+enumeratedClass +intersectionClass
IndividualForEnumeratedClass
+OWLoneOf
0..*
Individual
OWL property restrictions describe special kinds of class descriptions, that may (or may not) be anonymous classes,
consisting of all individuals that satisfy the restriction, as shown in Figure 11.4.
OWL distinguishes two kinds of property restrictions: value constraints and cardinality constraints. OWL value
constraints are used to constrain the range of a property when applied to the particular class description, which is distinct
from the concept of an rdfs:range property (which is essentially global and applies to all cases where the property is
used). OWL cardinality constraints are similar to UML multiplicities, and constrain the number of values a property can
have, again in the context of the particular class description it is applied to.
The three types of advanced class constructors that are used in Description Logic can be viewed as representing the AND,
OR, and NOT operators on classes. The corresponding operators have the standard set-operator names: intersection,
union, and complement. These language constructs also share the characteristic that they can contain nested class
descriptions, either one (complement) or more (union, intersection).
An owl:complementOf statement describes a class for which the class extension contains exactly those individuals that
do not belong to the class extension of the class description that is the object of the statement. It is analogous to logical
negation: the class extension consists of those individuals that are NOT members of the class extension of the
complement class.
Attributes
None
Associations
Constraints
None
Semantics
11.3.2 EnumeratedClass
Description
A class description of the “enumeration” kind is defined with the owl:oneOf property. The value of this built-in OWL
property must be a list of individuals that are the instances of the class. This enables a class to be described by
exhaustively enumerating its instances. The class extension of a class described with owl:oneOf contains exactly the
enumerated individuals, no more, no less. The list of individuals is typically represented with the help of the RDF
construct rdf:parseType="Collection" that provides a convenient shorthand for writing down a set of list elements.
Attributes
None
Associations
• OWLoneOf: Individual [0..*] in association EnumeratedClassForIndividual - links a class to the list of individuals that
are its instances.
Constraints
[1] The set of individuals specified represents a complete definition of the class extension.
Note that use of an enumeration presumes that the class extension is complete. Also, the elements of an enumerated class
are not necessarily unique and no unique names assumption applies.
11.3.3 Individual
Description
Individuals are defined with individual axioms (also called “facts”). Two types of facts are supported in OWL: (1) Facts
about class membership and property values of individuals, and (2) Facts about individual identity. Many facts are
statements that define class membership of individuals and property values of individuals; these can also refer to
anonymous individuals.
Attributes
None
Associations
• allDifferent: OWLAllDifferent [0..*] in association DistinctIndividuals - links an individual to an idiomatic class,
OWLAllDifferent, of which it is a member, indicating that it is pairwise disjoint with (unique from) the other members
of the class.
• differentIndividual: Individual [0..*] in association DifferentIndividual - links an individual to another individual that
it is different from (pairwise disjoint with).
• OWLdifferentFrom: Individual [0..*] in association DifferentIndividual - links an individual to another individual that
it is different from (pairwise disjoint with).
• sameIndividual: Individual [0..*] in association SameIndividual - links an individual to another individual that it is
equal to (the same as).
• OWLsameAs: Individual [0..*] in association SameIndividual - links an individual to another individual that it is equal
to (the same as).
Constraints
No additional constraints
Semantics
Note that individuals in OWL have a “default type” (i.e., owl:Thing), and can have zero or more explicit “types” (i.e.,
can be members of zero or more classes in addition to owl:Thing). What this means is that one can say that an
individual exists in an OWL ontology without necessarily saying anything about its class membership, other properties it
may have, or the values for any properties it may have. This is common in ontology development, unlike more traditional
UML modeling. Multiple inheritance is also supported. See the formal [OWL S&AS] for additional semantics.
The owl:intersectionOf property links a class to a list of class descriptions. An owl:intersectionOf statement
describes a class for which the class extension contains precisely those individuals that are members of the class extension
of all class descriptions in the list.
Attributes
None
Associations
Constraints
No additional constraints
Semantics
11.3.5 OWLClass
Description
A class description describes an OWL class, either by a class name or by specifying the class extension of an unnamed
anonymous class.
Attributes
• isDeprecated: Boolean [0..1] - indicates that use of this class description is deprecated.
Associations
• complementClass: ComplementClass [0..*] in association ComplementClassForComplement - links a class to another
class defined as its set complement.
• disjointClass: OWLClass [0..*] in association DisjointWith - links a class to zero or more classes that it is disjoint with.
• OWLdisjointWith: OWLClass [0..*] in association DisjointWith - links a class to zero or more classes that it is disjoint
with.
• equivalentClass: OWLClass [0..*] in association EquivalentClass - links a class to zero or more classes that it is
considered equivalent to.
• OWLequivalentClass: OWLClass [0..*] in association EquivalentClass - links a class to zero or more classes that it is
considered equivalent to.
• unionClass: UnionClass [0..*] in association UnionClassForUnion - links a class to zero or more unions that it
participates in.
Constraints
No additional constraints
Semantics
11.3.6 OWLRestriction
Description
The class owl:Restriction is defined as a subclass of owl:Class. A restriction class should have exactly one triple
linking the restriction to a particular property, using the owl:onProperty property. The restriction class should also have
exactly one triple that represents the value or cardinality constraint on the property under consideration, e.g., that the
cardinality of the property is exactly 1.
Property restrictions can be applied both to datatype properties (properties for which the value is a data literal) and object
properties (properties for which the value is an individual).
Attributes
None
Associations
• OWLonProperty: RDFProperty [1] in association RestrictionOnProperty - links an OWL restriction class to the
property that constrains it.
Constraints
[1] A restriction class must have exactly one number or value constraint.
Semantics
The owl:unionOf property links a class to a list of class descriptions. An owl:unionOf statement describes an
anonymous class for which the class extension contains those individuals that occur in at least one of the class extensions
of the class descriptions in the list.
Attributes
None
Associations
• OWLunionOf: OWLClass [0..*] in association UnionClassForUnion - links a union class to the class descriptions that
participate in the union.
Constraints
No additional constraints
Semantics
AllValuesFromDataRange
In place of the RDF datatypes, OWL provides two constructs for defining a range of data values, namely (1) an
enumerated datatype, which is an enumerated list of literals or (2) it identifies a specific datatype class from the RDF
datatypes (e.g., xsd:integer) that a value in the data range must reflect.
Attributes
None
Associations
• datatype: RDFSDatatype [0..1] in association DataTypeForDataRange - links a data range to the datatype that fills its
role.
• OWLoneOf: RDFSLiteral [0..*] in association DataElementsForDataRange - links a data range to the enumerated list
of literals that fill its role.
Constraints
[1] An OWLDataRange can be connected to 1 RDFSDatatype or to 1 or more RDFSLiterals, but not to both
(RDFSDatatype and RDFSLiteral).
Semantics
No additional semantics
Description
The cardinality constraint owl:cardinality is a built-in OWL property that links a restriction class to a data value
belonging to the range of the XML Schema datatype xsd:nonNegativeInteger. A restriction containing an
owl:cardinality constraint describes a class of all individuals that have exactly N semantically distinct values
(individuals or data values) for the property concerned, where N is the value of the cardinality constraint. Syntactically,
the cardinality constraint is represented as an RDF property element with the corresponding rdf:datatype attribute.
Attributes
None
• OWLcardinality: TypedLiteral [1] in association Cardinality - links a property to the cardinality of its range.
Constraints
[1] The datatype of the TypedLiteral for owl:cardinality must be xsd:nonNegativeInteger.
Semantics
No additional semantics
11.3.9.2 MaxCardinalityRestriction
Description
The cardinality constraint owl:maxCardinality is a built-in OWL property that links a restriction class to a data value
belonging to the value space of the XML Schema datatype xsd:nonNegativeInteger. A restriction containing an
owl:maxCardinality constraint describes a class of all individuals that have at most N semantically distinct values
(individuals or data values) for the property concerned, where N is the value of the cardinality constraint. Syntactically,
the cardinality constraint is represented as an RDF property element with the corresponding rdf:datatype attribute.
Attributes
None
Associations
• OWLmaxCardinality: TypedLiteral [1] in association MaxCardinality - links a property to the maximum cardinality of
its range.
Constraints
[1] The datatype of the TypedLiteral for owl:maxCardinality must be xsd:nonnegativeInteger.
Semantics
No additional semantics
11.3.9.3 MinCardinalityRestriction
Description
The cardinality constraint owl:minCardinality is a built-in OWL property that links a restriction class to a data value
belonging to the value space of the XML Schema datatype xsd:nonNegativeInteger. A restriction containing an
owl:minCardinality constraint describes a class of all individuals that have at least N semantically distinct values
(individuals or data values) for the property concerned, where N is the value of the cardinality constraint. Syntactically,
the cardinality constraint is represented as an RDF property element with the corresponding rdf:datatype attribute.
Attributes
None
• OWLminCardinality: TypedLiteral [1] in association MinCardinality - links a property to the minimum cardinality of
its range.
Constraints
[1] The datatype of the TypedLiteral for owl:minCardinality must be xsd:nonnegativeInteger.
Semantics
No additional semantics
Description
An AllValuesFromRestriction describes a class for which all values of the property under consideration are either
members of the class extension of the class description or are data values within the specified data range. In other words,
it defines a class of individuals x for which holds that if the pair (x, y) is an instance of P (the property concerned), then
y should be an instance of the class description or a value in the data range, respectively.
Attributes
None
Associations
• OWLallValuesFromClass: OWLClass [0..1] in association AllValuesFromClass - links the restriction class to the class
description containing all of the individuals in its range.
Constraints
[1] An AllValuesFromRestriction identifies either one OWLClass or one OWLDataRange through either the
AllValuesFromClass association or the AllValuesFromDataRange association, respectively.
Semantics
An owl:allValuesFrom constraint is analogous to the universal (for-all) quantifier of Predicate logic - for each instance
of the class that is being described, every value for P must fulfill the constraint.
11.3.12.2 HasValueRestriction
Description
A HasValueRestriction describes a class of all individuals for which the property concerned has at least one value
semantically equal to V (it may have other values as well).
Attributes
None
Associations
• OWLhasIndividualValue: Individual [0..1] in association HasIndividualValue - links the restriction class to the class
description containing the individual that fills its value role.
• OWLhasLiteralValue: RDFSLiteral [0..1] in association HasLiteralValue -links the restriction class to the literal that
fills its value role.
Constraints
[1] A HasValueRestriction links to only one value, either an individual through OWLhasIndividualValue or a
literal through OWLhasLiteralValue.
Semantics
No additional semantics
11.3.12.3 SomeValuesFromRestriction
Description
A SomeValuesFromRestriction describes a class for which at least one value of the property under consideration is either
a member of the class extension of the class description or is a data value within the specified data range. In other words,
it defines a class of individuals x for which there is at least one y (either an instance of the class description or value in
the data range) such that the pair (x, y) is an instance of P (the property concerned). This does not exclude that there are
other instances (x, y') of P for which y' does not belong to the class description or data range.
None
Associations
• OWLsomeValuesFromClass: OWLClass [0..1] in association SomeValuesFromClass - links the restriction class to a
class description containing at least one of the values in its range.
Constraints
[1] A SomeValuesFromRestriction identifies either one OWLClass or one OWLDataRange through either the
SomeValuesFromClass association or the SomeValuesFromDataRange association, respectively.
Semantics
An owl:someValuesFrom constraint is analogous to the existential (there-exists) quantifier of Predicate logic - for each
instance of the class that is being described, at least one value for P must fulfill the constraint.
The distinction made between kinds of annotation properties (i.e., annotation vs. ontology properties) are needed to
support OWL DL semantics. In addition, a number of property axioms are provided for property characterization.
Note: Certain information regarding OWL property inheritance, for example whether or not a particular object or
datatype property is also functional, may not be accessible to some applications due to issue #9466 regarding multiple
classification in MOF. See Annex F for details on how to work around this until the MOF issue is adequately addressed
and MOF tool support for multiple classification is available.
+OWLequivalentProperty
0..* EquivalentProperty
OWLAnnotationProperty OWLOntologyProperty Property 0..*
isDeprecated : Boolean [0..1] +equivalentProperty
+OWLinverseOf
0.. * InverseProperty
FunctionalProperty OWLDatatypeProperty OWLObjectProperty 0..*
+inverseProperty
11.4.1 FunctionalProperty
Description
A functional property is a property that can have only one (unique) value y for each instance x, i.e., there cannot be two
distinct values y1 and y2 such that the pairs (x, y1) and (x, y2) are both instances of this property. Both object properties
and datatype properties can be declared as “functional.” For this purpose, OWL defines the built-in class
owl:FunctionalProperty as a special subclass of the RDF class rdf:Property.
Attributes
None
Associations
Constraints
No additional constraints
Semantics
Note that owl:FunctionalProperty specifies global cardinality constraints. That is, no matter which class the property
is applied to, the cardinality constraints must hold. This is different from the cardinality constraints contained in property
restrictions. The latter are class descriptions and are only enforced on the property when applied to that class.
If a property is declared to be inverse-functional, then the object of a property statement uniquely determines the subject
(some individual). More formally, if we state that P is an owl:InverseFunctionalProperty, then this asserts that a
value y can only be the value of P for a single instance x, i.e., there cannot be two distinct instances x1 and x2 such that
both pairs (x1, y) and (x2, y) are instances of P.
Syntactically, an inverse-functional property axiom is specified by declaring the property to be an instance of the built-in
OWL class owl:InverseFunctionalProperty, which is a subclass of the OWL class owl:ObjectProperty.
Attributes
None
Associations
• Specialize Class ObjectProperty
Constraints
No additional constraints
Semantics
One difference with functional properties is that for inverse-functional properties no additional object-property or
datatype-property axiom is required: inverse-functional properties are by definition object properties.
Note that owl:InverseFunctionalProperty specifies global cardinality constraints. That is, no matter which class the
property is applied to, the cardinality constraints must hold. This is different from the cardinality constraints contained in
property restrictions. The latter are class descriptions and are only enforced on the property when applied to that class.
11.4.3 OWLAnnotationProperty
Description
OWL Full does not put any constraints on annotations in an ontology. OWL DL allows annotations on classes, properties,
individuals and ontology headers, as outlined in Section 11.8.1, “Classes in OWL DL.”
• owl:versionInfo
• rdfs:label
• rdfs:comment
• rdfs:seeAlso
• rdfs:isDefinedBy
In addition to the associations given in the metamodel representing these properties, they are defined in the model library
provided in Annex A.
None
Associations
• Specialize Class RDFProperty
Constraints
[1] The object of an annotation property must be RDFSLiteral, Individual, or URIReference.
Semantics
No additional semantics
11.4.4 OWLDatatypeProperty
Description
Datatype properties are used to link individuals to data values. A datatype property is defined as an instance of the built-
in OWL class owl:DatatypeProperty.
Attributes
None
Associations
Constraints
[1] The range of an OWLDatatypeProperty is restricted to the set of data values, i.e., a member of the class
extension of RDFSLiteral or an instance of OWLDataRange.
context OWLDatatypeProperty RangeIsLiteral inv:
self.RDFSrange.oclIsKindOf (RDFSLiteral) or self.RDFSrange.oclIsKindOf (OWLDataRange)
Semantics
11.4.5 OWLObjectProperty
Description
An object property relates an individual to other individuals. An object property is defined as an instance of the built-in
OWL class owl:ObjectProperty.
Attributes
None
Associations
Constraints
[1] The range of an OWLObjectProperty is restricted to the set of individuals, i.e., a member of the class extension
of OWLClass.
context OWLObjectPropertyRangeIsOWLClass inv:
(self.RDFSrange.oclIsKindOf (OWLClass))
Semantics
11.4.6 OWLOntologyProperty
Description
A document describing an ontology typically contains information about the ontology itself. An ontology is a resource, so
it may be described using properties from the OWL and other namespaces. An ontology property is essentially an
annotation property that allows us to say things about the current and other ontologies, such as indicating that a particular
ontology is a prior version of the current ontology.
• owl:imports
• owl:priorVersion
• owl:backwardCompatibleWith
• owl:incompatibleWith
Attributes
None
Associations
• Specialize Class RDFProperty
Constraints
[1] Instances of owl:OntologyProperty must have the class owl:Ontology as their domain and range.
context OWLOntologyPropertyDomainRangeIsOWLOntology inv:
(self.RDFSdomain.oclIsKindOf(OWLOntology) and
self.RDFSrange.oclIsKindOf(OWLOntology))
Semantics
No additional semantics
Property is an abstract class that simplifies representation of property equivalence and deprecation, simplifies constraints
for OWL DL and OWL Full, and facilitates mappings with other metamodels.
Attributes
Associations
• equivalentProperty: Property [0..*] in association EquivalentProperty - links a property to zero or more properties that
it is considered equivalent to.
Constraints
No additional constraints. Note that in OWL as in RDF, properties are required to have URI references, which in this case
are inherited from RDFProperty.
Semantics
No additional semantics
11.4.8 SymmetricProperty
Description
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. Syntactically, a property is defined as symmetric by making it an instance of the built-in OWL class
owl:SymmetricProperty, a subclass of owl:ObjectProperty.
Attributes
None
Associations
Constraints
[1] The domain and range of a symmetric property must be the same.
Semantics
No additional semantics
When one defines a property P to be a transitive property, this means that if a pair (x, y) is an instance of P, and the pair
(y, z) is also instance of P, then we can infer the pair (x, z) is also an instance of P.
Syntactically, a property is defined as being transitive by making it an instance of the built-in OWL class
owl:TransitiveProperty, which is defined as a subclass of owl:ObjectProperty.
Attributes
None
Associations
Constraints
No additional constraints
Semantics
No additional semantics
Many languages have a so-called “unique names” assumption: different names refer to different things in the world. On
the web, such an assumption is not possible. For example, the same person could be referred to in many different ways
(i.e., with different URI references). For this reason OWL does not make this assumption. Unless an explicit statement is
being made that two URI references refer to the same or to different individuals, OWL tools should in principle assume
either situation is possible. Figure 11.6 depicts the set of constructs available to state facts about individual identity in
OWL.
+OW LdifferentFrom
0..*
DifferentIndividual
+differentIndividual Individual
0..* DistinctIndividuals OW LAllDi fferent
2..* 0..*
0..*
+sameIndividual +OW LdistinctMembers +allDifferent
SameIndividual 0..*
+OW LsameAs
11.5.1 OWLAllDifferent
Description
For ontologies in which the unique-names assumption holds, the use of owl:differentFrom is likely to lead to a large
number of statements, as all individuals have to be declared pairwise disjoint. For such situations OWL provides a special
idiom in the form of the construct owl:AllDifferent. owl:AllDifferent is a special built-in OWL class, for which
the property owl:distinctMembers is defined, which links an instance of owl:AllDifferent to a list of individuals.
The intended meaning of such a statement is that all individuals in the list are all different from each other.
Attributes
No additional attributes
Associations
Constraints
[1] All members of a particular instance of the class owl:AllDifferent are pairwise disjoint from each other.
Semantics
No additional semantics
OWL makes use of the RDF datatyping scheme, which provides a mechanism for referring to XML Schema datatypes
[XML Schema Datatypes]. Note that only a subset of the XML Schema datatypes are recommended for use in RDF and
OWL, as discussed in Chapter 10.
OWL provides an additional construct for defining a range of data values, namely an enumerated datatype. This datatype
format makes use of the owl:oneOf construct, that is also used for describing an enumerated class. In the case of an
enumerated datatype, the subject of owl:oneOf is a blank node of class owl:DataRange and the object is a list of
literals.
RDFSClass
(from RDFS)
ElementsForDataRange
+OWLoneOf
0.. *
RDFSLiteral
(from RDFBase)
Additionally, we want to be able to define the set of constraints that will allow us to differentiate between an ontology
that conforms to OWL DL and one that is OWL Full compliant. In Figure 11.8, we provide the notion of an abstract
OWLUniverse class, which facilitates ontology traversal for mapping purposes as well as utility in defining constraints for
distinguishing these two dialects of OWL.
11.7.1 OWLUniverse
Description
This class is intended to simplify packaging / mapping requirements for cases where the ability to determine the set of
classes, individuals, and properties that together comprise a particular OWL ontology is required.
Attributes
No additional attributes
Associations
• ontology: OWLOntology [1..*] in association UniverseForOntology - specifies one or more OWLOntology that
members of this universe are associated with/describe.
Constraints
No additional constraints
Semantics
No additional semantics
• owlUniverse: OWLUniverse [*] in association UniverseForOntology - specifies an OWL universe(s) for this ontology.
• There are severe limitations on the use of RDF vocabulary in OWL DL [OWL S&AS].
• OWL, RDF, and RDFS vocabularies cannot be modified by statements in OWL DL.
11.8.2.1 AllValuesFromRestriction
Constraints
[1] If the property linked to the AllValuesFromRestriction is an OWLDatatypeProperty, then the restriction is
linked to exactly 1 OWLDataRange and 0 OWLClass.
[2] If the property linked to the AllValuesFromRestriction is an OWLObjectProperty, the restriction is linked to
exactly 1 OWLCLass and 0 OWLDataRange.
11.8.2.2 HasValueRestriction
Constraints
[1] If the property linked to the HasValueRestriction is an OWLDatatypeProperty, then the restriction is linked to
exactly 1 RDFSLiteral and 0 Individual.
[2] If the property linked to the HasValueRestriction is an OWLObjectProperty, then the restriction is linked to
exactly 1 Individual and 0 RDFSLiteral.
11.8.2.3 SomeValuesFromRestriction
Constraints
[1] If the property linked to the SomeValuesFromRestriction is an OWLDatatypeProperty, then the restriction is
linked to exactly 1 DataRange and 0 Class.
[2] If the property linked to the SomeValuesFromRestriction is an OWLObjectProperty, then the restriction is
linked to exactly 1 Class and 0 DataRange.
Description
Constraints
[1] The association RDFSrange cannot be used with an OWLAnnotationProperty.
[2] The association RDFSdomain cannot be used with an OWLAnnotationProperty.
[3] Hierarchies of annotation properties are disallowed: the association RDFSsubPropertyOf cannot be used with
an OWLAnnotationProperty.
11.8.3.2 OWLDatatypeProperty
Description
The following additional restrictions apply to the use of datatype properties in OWL DL:
Constraints
[1] If the association OWLequivalentProperty is defined on an OWLDatatypeProperty, the Property on the other
end of that equivalence must also be of type OWLDatatypeProperty.
[2] If the association RDFSsubPropertyOf is defined on an OWLDatatypeProperty, the RDFProperty on the other
end of the generalization must also be of type OWLDatatypeProperty.
[3] The range of OWLDatatypeProperty (association RDFSrange on superclass RDFProperty) is limited to
OWLDataRange.
11.8.3.3 OWLObjectProperty
Description
The following additional restrictions apply to the use of object properties in OWL DL:
• The sets of object properties, datatype properties, annotation properties, and ontology properties must be mutually
disjoint.
• Cardinality constraints (local or global) cannot be applied to transitive properties, to their inverses, or to any of their
super properties.
• Inverse functional, symmetric and transitive properties must be object properties.
Constraints
[1] If the association OWLEquivalentProperty is defined on an OWLObjectProperty, the Property on the other end
of the equivalence must also be of type OWLObjectProperty.
[2] If the association RDFSsubPropertyOf is defined on an OWLObjectProperty, the RDFProperty on the other end
of the generalization must also be of type OWLObjectProperty.
[3] The range of OWLObjectProperty (association RDFSrange on superclass RDFProperty) is limited to
OWLClass.
11.8.3.4 OWLOntologyProperty
Description
Similar restrictions to those on the use of annotation properties apply to ontology properties:
Constraints
[1] The association RDFSrange cannot be used with an OWLOntologyProperty.
[2] The association RDFSdomain cannot be used with an OWLOntologyProperty.
[3] Hierarchies of ontology properties are disallowed: RDFSsubPropertyOf cannot be used with an
OWLOntologyProperty.
11.8.3.5 TransitiveProperty
Constraints
[1] No local or global cardinality constraints can be declared on a transitive property or on any of its super
properties, nor on the inverse of the property or any of the inverse’s superProperty.
12.1 Overview
Common Logic (CL) is a first-order logical language intended for information exchange and transmission over an open
network [ISO 24707] . It allows for a variety of different syntactic forms, called dialects, all expressible within a common
XML-based syntax and all sharing a single semantics. The language has declarative semantics, which means that it is
possible to understand the meaning of expressions written in CL without requiring an interpreter to manipulate those
expressions. CL is logically comprehensive – at its most general, it provides for the expression of arbitrary logical
expressions. CL has a purely first-order semantics, and satisfies all the usual semantic criteria for a first-order language,
such as compactness and the downward Skolem-Löwenheim property.
Motivation for its consideration as an integral component of the Ontology Definition Metamodel (ODM) includes:
• The potential need by ontologists using the ODM to be able to represent constraints and rules with expressiveness
beyond that supported by description logics (e.g., for composition of semantic web services), as highlighted in Chapter
7, Usage Scenarios and Goals.
• The availability of normative mappings from CL to syntactic forms for several commonly used knowledge
representation standards, defined in [ISO 24707], including the Knowledge Interchange Format [KIF] and Conceptual
Graphs [CGS].
• The availability of a normative XML-based surface syntax for CL, called XCL (also defined in [ISO 24707], which
dramatically increases its potential for use in web-based applications.
• The availability of a direct mapping from the Web Ontology Language (OWL) [OWL S&AS] to CL, such that CL
reasoners can leverage both the ontologies expressed in OWL and constraints written in CL to solve a wider range of
problems than can be addressed by OWL alone (see Chapter 18, Mapping RDFS and OWL to CL).
In general, first order logic provides the basis for most commonly used knowledge representation languages, including
relational databases; more application domains have been formalized using first order logic than any other formalism – its
meta-mathematical properties are thoroughly understood. CL in particular provides a modern form of first order logic that
takes advantage of recent insights in some of these application areas including the semantic web.
First order logic can also provide the formal grounding for business semantics. Although work on the OMG’s Business
Semantics For Business Rules (BSBR) RFP was initially done in parallel with the ODM, there has been significant effort
to leverage CL as the first order logic basis for the Semantics of Business Vocabulary and Business Rules (SBVR)
specification. Common Logic (and thus ODM) now supports irregular sentences, a recent addition to the abstract syntax
of CL required for the SBVR modality representations, for example. Subsequent versions of both specifications will be
amended to accommodate additional interoperability requirements to the extent possible.
The complete syntax and formal semantics for CL are documented in [ISO 24707] and are considered essential to
understanding the expressions that might be imported, managed, manipulated, or generated by any ODM/CL-compliant
tool.
1
+body 0..*
+t ext
Name
PhraseForText
name : String +phrase
0.. *
0..*
+excludedName ModuleBody
Phrase CommentedText
ExcludedName
12.2.1 Comment
Description
A Comment is a “piece of data” that provides the facility for commenting on a particular phrase or set of sentences.
Common Logic places no restrictions on the nature of comments.
• comment: String [1] – the character string that is the comment on the phrase.
Associations
• commentedText: Text [0..1] in association CommentedText – the text to which the comment applies.
Constraints
None
Semantics
None
12.2.2 ExclusionSet
Description
A module may optionally have an exclusion list of names whose denotations might be excluded from the local domain of
discourse. These are called non-discourse names.
Attributes
None
Associations
• excludedName: Name [0..*] in association ExcludedName – the names that are members of the ExclusionSet.
• module: Module [0..*] in association ExcludedSet – the module(s) that excludes this set of names.
Constraints
None
Semantics
An ExclusionSet essentially represents some set of non-discourse names as they relate to a particular domain of discourse.
See [ISO 24707] for additional detail.
12.2.3 Identifier
Description
An identifier is a name explicitly used to identify a module or piece of common logic text.
Attributes
None
• context: Importation [0..*] in association NameForImportation – links an identifier to an importation that references it.
• module: Module [1] in association ModuleName – links an identifier to the module it names.
• namedText: Text [0..1] in association NameForText – links an identifier to the text it names.
Constraints
None
Semantics
Names used to name texts on a network are understood to be rigid and to be global in scope, so that the name can be used
to identify the thing named – in this case, the Common Logic text or module – across the entire communication network.
(See [RFC2396] for further discussion.) A name that is globally attached to its denotation in this way is an identifier, and
is typically associated with a system of conventions and protocols that govern the use of such names to identify, locate,
and transmit pieces of information across the network on which the dialect is used. While the details of such conventions
are beyond the scope of this specification, we can summarize their effect by saying that the act of publishing a named
Common Logic text (or module) is intended to establish the name as a rigid identifier of the text, and Common Logic
acknowledges this by requiring that all interpretations shall conform to such conventions when they apply to the network
situation in which the publication takes place.
Note that in the case of an importation, the name serves to identify the module, which is accomplished through a double
interpretation in the semantics. The ‘import’ condition is that (import x) is true in I just when I(I(x)) is true. In other
words, interpreting an identifier gets what it denotes. If the name happens to be a CL ontology (I(x) is an ontology), then
interpreting it again I(I(x)) returns a truth-value; thus, (import x) says that x is an ontology that *this* ontology (the one
doing the importing) asserts to be true.
12.2.4 Importation
Description
An importation contains a name. The intention is that the name is an identifier of a piece of Common Logic content
represented externally to the text, and the importation re-asserts that content in the text.
Attributes
None
Associations
• assertedContent: Identifier [1] in association NameForImportation – the name of the module to be imported; the name
argument of an importation will usually be a URI.
Constraints
None
An import construction requires that we assume the existence of a global module-naming convention, and that module
names refer to entities in formal interpretations. Common Logic uses the same semantic web conventions used in RDF
and OWL, based on W3C recommendation for representing namespaces in XML (see “[XMLNS]” on page 4). The
meaning of an importation phrase is that the name it contains shall be understood to identify some Common Logic
content, and the importation is true just when that content is true. Thus, an importation amounts to a virtual ‘copying’ of
some Common Logic content from one ‘place’ to another. This idea of ‘place’ and ‘copying’ can be understood only in
the context of deploying logical content on a communication network. A communication network, or simply a network, is
a system of agents that can store, publish, or process common logic text, and can transmit common logic text to one
another by means of information transfer protocols associated with the network.
12.2.5 Module
Description
A module consists of a name, an optional set of names called an exclusion set, and a text called the body text. The module
name indicates the “local universe of discourse” in which the text is understood; the exclusion list indicates any names in
the text that are excluded from the local domain (i.e., variables whose scope is external to the local domain).
Attributes
None
Associations
• body: Text [1] in association ModuleBody – the body, or set of phrases, that are contained in the module.
• exclusionSet: ExclusionSet [0..1] in association ExcludedSet – the optional set of names, or exclusion list, associated
with a given module.
• localDomain: Identifier [1] in association ModuleName – the logical name associated with a module (for most
applications, particularly those that are web based, module names must be unique).
Constraints
In cases where CL is used to define ontologies for the Web, module names take the form of Uniform Resource Identifiers
[RDF Syntax] or URI references, and are global (thus must be unique).
Semantics
A module provides the scoping mechanism for a CL ontology, corresponding to an RDF graph [RDF Primer] or
document, or to an OWL ontology. The name of a module should be the name of the corresponding RDF document in
cases where CL constraints are associated with an RDFS/OWL ontology, and has the same URI or URI reference (i.e.,
that of the RDFS/OWL ontology).
The CL syntax provides for modules to state an intended domain of discourse, to relate modules explicitly to other
domains of discourse, and to express intended restrictions on the syntactic roles of symbols. This feature is critical to
component-based ontology (or micro-theory) construction, and therefore relevant to any MDA-based authoring
environment.
A name is any lexical token, or character string, which is understood to refer to something in the universe. Part of the
design philosophy of CL is to avoid syntactic distinctions between name types, allowing ontologies freedom to use names
without requiring mechanisms for syntactic alignment. Names are primitive referring elements in CL, and refer to
elements of a particular ontology, such as module names, role names, relations, or numbers.
Dialects intended for use on the Web should allow Universal Resource Identifiers and URI references [RDF Syntax] to
be used as names. Common Logic dialects should define names in terms of Unicode [ISO 10646] conventions.
Attributes
Associations
• exclusionSet: ExclusionSet [0..*] in association ExcludedName – the optional exclusion list referring to the name.
• binding: Binding [1] in association BoundName – associates a name (variable) with the related binding (i.e., the name
becomes a binding) in quantified sentences.
Constraints
[1] The lexical syntax for several CL dialects identifies a number of rules for specifying valid names that cannot be
expressed in OCL, and are thus delegated to CL parsers (such as identification of special characters that cannot
be embedded in names, the requirement for conformance to Unicode conventions, additional constraints on
logical names that are URIs or URI references, and so forth).
[2] Names and sequence markers are disjoint syntax categories, and each is disjoint from all other syntax
categories.
Semantics
The only undefined terms in the CL abstract syntax are name and sequence marker. The only required constraint on these
is that they must be exclusive. Common Logic does not require names to be distinguished from variables, nor does it
require names to be partitioned into distinct classes such as relation, function or individual names, or impose sortal
restrictions on names. Particular Common Logic dialects may make these or other distinctions between subclasses of
names, and impose extra restrictions on the occurrence of types of names or terms in expressions - for example, by
requiring that bindings be written with a special variable prefix, as in KIF, or with a particular style, as in Prolog; or by
requiring that operators be in a distinguished category of relation names, as in conventional first-order syntax.
A dialect may impose particular semantic conditions on some categories of names, and apply syntactic constraints to limit
where such names occur in expressions. For example, the core syntax treats numbers as having a fixed denotation, and
prohibits their use as identifiers. A dialect may require some names to be non-discourse names. This requirement may be
imposed by, for example, partitioning the vocabulary, or by requiring names that occur in certain syntactic positions to be
non-denoting. A dialect with non-discourse names is called segregated.
A phrase is a syntactic unit of text. A phrase is either a comment, or a module, or a sentence, or an importation, or a
phrase with an attached comment.
Attributes
None
Associations
• text: Text [0..*] in association PhraseForText – the text(s) in which the phrase occurs.
Constraints
[1] Module, Importation, Sentence, and Comment are specializations of Phrase and form a disjoint partition, as
follows:
context Phrase inv XOR:
(self.oclIsKindOf(Module) xor self.oclIsKindOf(Importation) xor
self.oclIsKindOf(Sentence) xor self.oclIsKindOf(Comment))
Semantics
No additional semantics
12.2.8 Sentence
Description
CL provides facilities for expressing several kinds of sentences, including atomic sentences as well as compound
sentences built up from atomic sentences or terms with a set of logical constructors. A sentence is either a quantified
sentence or a Boolean sentence or an atom, or a sentence with an attached comment, or an irregular sentence. CL
sentences can be classified (or used) as phrases, as stated above and as shown in Figure 12.1.
The convention used in CL for expressing sentences differs from the approach taken in the informative DL metamodel. In
the DL case, constructors are uniquely defined, whereas in CL the constructors are an integral part of the sentence, named
for the kind of construction used in the sentence.
Attributes
None
Associations
• biconditional: Biconditional [0..1] in association LvalueForBiconditional – associates a sentence as the “lvalue” (or
left-hand side) of a Biconditional or biconditional relation.
• biconditional: Biconditional [0..1] in association RvalueForBiconditional – associates a sentence as the “rvalue” (or
right-hand side) of a Biconditional or biconditional relation.
• comment: CommentedSentence [0..1] in association CommentForSentence – provides the facility for commenting any
given CL sentence.
• disjunction: Disjunction [0..1] in association Disjunction – associates a sentence to its disjuncts in a disjunction.
Constraints
Semantics
No additional semantics
12.2.9 Text
Description
Text is a collection of phrases (set, sequence, or bag optionally specified by a CL dialect) optionally identified by a name.
A module is a named piece of text with an optional exclusion set containing names considered to be outside the domain
of discourse for the module.
Attributes
None
Associations
• commentForText: Comment [0..*] in association CommentedText – optional comment(s) associated with the text.
• identifierForText: Identifier [0..1] in association NameForText – links a text with an identifier in a named text.
• phrase: Phrase [0..*] in association PhraseForText – the phrase(s) or sentence(s) that comprise the text.
• moduleForBody: Module [0..*] in association ModuleBody – the module(s) owning the text.
Constraints
None
The semantics of Common Logic is defined in terms of a satisfaction relation between CL text and structures called
interpretations. All dialects must apply these semantic conditions to all common logic expressions, that is, to any of the
forms given in the abstract syntax. They may in addition apply further semantic conditions to subclasses of common logic
expressions, or to other expressions.
A vocabulary is a set of names and sequence markers. The vocabulary of a Common Logic text is the set of names and
sequence markers that occur in the text. In a segregated dialect, vocabularies are partitioned into denoting names and non-
discourse names.
An interpretation I of a vocabulary V is a set UI, the universe, with a distinguished non-empty subset DI, the domain of
discourse, or simply domain, and four mappings: relI from UI to subsets of DI*, funI from UI to FunctionalTerms DI*->DI,
(which we will also consider to be the set DI* x DI), intI from names in V to UI, and seqI from sequence markers in V to
DI*. If the dialect is segregated, then intI(x) is in DI if and only if x is a denoting name. If the dialect recognizes irregular
sentences, then they are treated as names of propositions, and intI also includes a mapping from the irregular sentences of
a text to the truth values {true, false}.
Intuitively, DI is the domain of discourse containing all the individual things the interpretation is ‘about’ and over which
the quantifiers range. UI is a potentially larger set of things that might also contain entities that are not in the universe of
discourse. All names are interpreted in the same way, whether or not they are understood to denote something in the
domain of discourse; this is why there is only a single interpretation mapping applying to all names regardless of their
syntactic role. In particular, relI(x) is in DI* even when x is not in D. When considering only segregated dialects, the
universe outside the domain may be considered to contain names and can be ignored; when considering only unsegregated
dialects, the distinction between universe and domain is unnecessary. The distinction is required in order to give a
uniform treatment of all dialects. Irregular sentences are treated as though they were arbitrary propositional variables.
A discussion of the semantics regarding text interpretation is given in “[ISO 24707]” on page 4, including distinctions in
quantifier scope, features enabling structured relationships among modules, closed-world and unique naming issues, and
so forth.
CommentForTerm OperatorForFunctionalTerm
+term +operator
1 1
Term SequenceMarker
An argument sequence is a finite ordered sequence of bindings, which are terms or sequence markers. A sequence may be
empty or may consist of a single sequence marker.
Attributes
None
Associations
Constraints
[1] The terms in an argument sequence are ordered.
Semantics
An argument sequence represents a sequence of argument terms. A sequence marker stands for a sequence of terms,
considered to be inserted into the sequence in place of the marker.
12.3.2 CommentedTerm
Description
Attributes
Associations
• term: Term [1] in association CommentForTerm – links the comment to the term
Constraints
None
Semantics
None
A FunctionalTerm consists of a term, called the operator, and a term sequence called the argument sequence, containing
terms called arguments.
Attributes
None
Associations
• argument: Argument [0..*] in association ArgumentSequenceForFunctionalTerm – links zero or more additional terms
(i.e., arguments) to a functional term.
Constraints
[1] The argument sequence of a functional term is ordered.
Semantics
12.3.4 SequenceMarker
Description
An argument sequence is a finite ordered sequence of bindings, which are terms or sequence markers. A sequence may be
empty or may consist of a single sequence marker. Atomic sentences consist of an application of one term, denoting a
relation to a finite sequence of other terms. Such argument sequences may be empty, but they must be present in the
syntax, as an application of a relation term to an empty sequence does not have the same meaning as the relation term
alone.
Attributes
None
Associations
• binding: Binding [1] in association BoundSequenceMarker – associates a sequence marker with the related binding in
quantified sentences.
Constraints
[1] Names and sequence markers are disjoint syntax categories, and each is disjoint from all other syntax
categories.
Sequence markers take Common Logic beyond first-order expressiveness. A sequence marker stands for an arbitrary
sequence of arguments. Sequence markers can be universally quantified, and a sentence containing such a quantifier has
the same semantic import as the infinite conjunction of all the expressions obtained by replacing the sequence marker by
a finite sequence of names, all universally quantified.
A dialect that does not provide for sequence markers, but is otherwise fully conformant, is a compact dialect, and may be
described as a fully conformant compact dialect if it provides for all other constructions in the abstract syntax. Additional
discussion on the semantics and use of sequence markers in CL is provided in the [ISO 24707] Common Logic
specification.
12.3.5 Term
Description
Attributes
None
Associations
• commentedTerm: CommentedTerm [0..1] in association CommentForTerm – provides the facility for commenting any
CL term.
• function: FunctionalTerm [0..*] in association OperatorForFunction – links an operator to the FunctionalTerm that it is
a part of.
• equation: Equation [0..*] in association LvalueForIdentity – links the term representing the ‘lvalue’ to an equation.
• equation: Equation [0..*] in association RvalueForIdentity – links the term representing the ‘rvalue’ to an equation.
Constraints
Semantics
0..* 1 1 1
+argument +predicate +lvalue +rvalue
{ordered} PredicateForAtomicSentence LvalueForEquation RvalueForE quat ion
+atomicSentence +equation +equation
0..* 0..* 0..*
SequenceMarker ArgumentSequenc eForAtomicSentence Atomi cSentence Equation
0..*
+atomicSentence
Atom
12.4.1 Atom
Description
An atom is either an equation containing two arguments that are terms, or consists of a term, called the predicate, and
term sequence called the argument sequence containing terms called arguments of the atom.
Attributes
None
Associations
Constraints
[1] The AtomicSentence/Equation partition is disjoint.
context Atom inv DisjointPartition:
(self.oclIsKindOf(AtomicSentence) xor self.oclIsKindOf(Equation))
Semantics
An atom, or atomic sentence, asserts that a relation holds between arguments. Its general syntactic form is that of a
relation term applied to an argument sequence.
12.4.2 AtomicSentence
Description
Attributes
None
• predicate: Term [1] in association PredicateForAtomicSentence – links a predicate to the relation (atomic sentence) it
participates in.
Constraints
None
Semantics
12.4.3 Equation
Description
An equation asserts that its arguments are equal and consists of exactly two terms.
Attributes
None
Associations
• lvalue: Term [1] in association LvalueForIdentity – associates a term as the “lvalue” of the equation (identity relation).
• rvalue: Term [1] in association RvalueForIdentity – associates a term as the “rvalue” of the equation (identity relation).
Constraints
None
Semantics
Equations are distinguished as a special category because of their special semantic role and special handling by many
applications. See additional discussion of the semantics of equations in CL in [ISO 24707].
1
+sentence
CommentForSentence
+comment
0..1
Atom BooleanSentence CommentedSentence IrregularSentence QuantifiedSentence
comment : String
12.5.1 Biconditional
Description
Attributes
None
Associations
• lvalue: Sentence [1] in association LvalueForBiconditional – associates exactly one sentence as the ‘lvalue’ of the
expression.
• rvalue: Sentence [1] in association RvalueForBiconditional – associates exactly one sentence as the ‘rvalue’ of the
expression.
Constraints
None
Semantics
This asserts that two sentences have the same truth value. See additional discussion of the semantics of sentences in CL
in [ISO 24707].
BooleanSentence is an abstract class representing boolean sentences. A Boolean sentence has a type, called a connective,
and a number of sentences called the components of the Boolean sentence. The number depends on the particular type.
Every Common Logic dialect shall distinguish the conjunction, disjunction, negation, implication, and biconditional types
with respectively any number, any number, one, two and two components.
Attributes
None
Associations
Constraints
None
Semantics
12.5.3 CommentedSentence
Description
This feature enables annotation of sentences.
Attributes
Associations
• sentence: Sentence [1] in association CommentForSentence – associates exactly one sentence as the argument of the
expression.
Constraints
None
Semantics
No additional sentences
Essentially, a conjunction means that all its components are true. Note that true is defined as the empty case of a
conjunction – there are no explicit definitions of true and false in CL. These definitions are conventional in formal logic
and knowledge representation work.
Attributes
None
Associations
• conjunct: Sentence [0..*] in association Conjunction – associates zero or more sentences as conjuncts of the
expression.
Constraints
None
Semantics
12.5.5 Disjunction
Description
Essentially, a disjunction means that at least one of its components is true. Note that false is defined as the empty case of
a disjunction.
Attributes
None
Associations
• disjunct: Sentence [0..*] in association Disjunction – associates zero or more sentences as disjuncts of the expression.
Constraints
None
12.5.6 ExistentialQuantification
Description
An existentially quantified sentence, consisting of (exists (var) body), asserts that some things exist in the universe
of discourse that satisfy the description in the body. An existentially quantified sentence means that its body is true for
some re-interpretation of its bindings. Bindings may be names or sequence markers, which are re-interpreted respectively
as referring to things or sequences of things, in the universe of discourse.
Attributes
None
Associations
Constraints
None
Semantics
See additional discussion of the semantics of sentences in CL in [ISO 24707].
12.5.7 Implication
Description
An implication, consisting of (implies s1 s2), asserts that it is
false if I(s1) = true and I(s2) = false, otherwise true.
Attributes
None
Associations
• antecedent: Sentence [1] in association AntecedentForImplication – associates exactly one sentence as the antecedent
of the expression.
• consequent: Sentence [1] in association ConsequentForImplication – associates exactly one sentence as the consequent
of the expression.
Constraints
None
12.5.8 IrregularSentence
Description
Provides the placeholder for irregular sentences in the metamodel, potentially for use with modal sentence requirements
for the Semantics for Business Vocabularies and Rules (SBVR) specification.
Attributes
None
Associations
Constraints
None
Semantics
None
12.5.9 Negation
Description
A negation, consisting of (not s), asserts that it is true if I(s) = false, otherwise false. Essentially, a
negation means that its inner sentence is false.
Attributes
None
Associations
• sentence: Sentence [1] in association NegatedSentence – associates exactly one sentence as the argument of the
expression.
Constraints
None
Semantics
QuantifiedSentence is an abstract class representing quantified sentences. A quantified sentence has a type, called a
quantifier, a finite sequence of names or sequence markers called bindings, and a sentence called the body of the
quantified sentence. Every Common Logic dialect shall distinguish the universal and the existential types of quantified
sentence.
Quantifiers may bind any number of variables; bindings may be restricted to a named category.
Attributes
None
Associations
• body: Sentence [1] in association QuantificationForSentence – associates exactly one sentence (body) with the
expression.
Constraints
None
Semantics
12.5.11UniversalQuantification
Description
A universally quantified sentence, consisting of (forall (var) body), asserts that everything that exists in the
universe of discourse satisfies the description in the body. A universally quantified sentence means that its body is true for
any interpretation of its bindings. It consists of a sequence of bindings and a body that is a sentence.
Attributes
None
Associations
Constraints
None
Semantics
Bool eanSentence
AntecedentForImplication LvalueForBiconditional
Conjunction Disjunction NegatedSentence RvalueForBiconditional
Consequent ForImplicat ion
There are no explicit 'true' and 'false' elements in the metamodel. These
are empty cases of Conjunction (true) and Disjunction (false). That is
why a Disjunction or Conjunction of zero sentences is allowed.
1
+body
QuantificationForSentence
+quantification {ordered}
0..1 +quantifiedSentence +binding
0..* Binding
QuantifiedSentence 0.. 1
BindingSequenceForQuantifiedSentence
1 1
+binding +binding
BoundName BoundSequenceMark er
UniversalQuantification Existenti alQuantification
+boundName +boundSequenceMarker
0..1 0..1
Name SequenceMarker
12.7.1 Binding
Description
A quantified sentence has (i) a type, called a quantifier, (ii) a finite, non-repeating sequence of names and sequence
markers called the binding sequence, each element of which is called a binding of the quantified sentence, and (iii) a
sentence called the body of the quantified sentence. A name or sequence marker that occurs in the binding sequence is
said to be bound in the body. Any name or sequence marker that is not bound in the body is said to be free in the body.
Attributes
None
Associations
• boundName: Name [0..1] in association BoundName - associates an optional name with a particular binding.
Constraints
No additional semantics.
FunctionalTerm term with operator o and term funI(I(o))(I(s)), i.e., the x such
sequence s: ([o][s]) that <(I(s),x)> is in (I(o))
Module, ExclusionSet, module with name N, exclusion set true if [I<L](B) = true and
Text L and body text B relI(I(N)) = UD[I<L]*, otherwise
false
The Topic Maps Meta-Model is defined based primarily upon ISO 13250-2 Data Model [TMDM] and to a lesser degree
ISO 13250-3 XML Syntax. The TMDM provides the most authoritative definition of the abstract syntax for Topic Maps.
The following discussion assumes a basic understanding of Topic Maps.
The TMDM includes UML diagrams illustrating its data structures and their relationships. However, the normative
specification is textual. The UML diagrams are informative only. The ODM includes a MOF 2 metamodel for Topic Maps
to provide such a normative metamodel, and because one of the objectives coming out of the usage requirements analysis
was to enable interoperability between UML, RDF, OWL CL, and Topic Maps. The latter requirement, in turn, requires a
TM metamodel to support mappings, XMI, Java API generation, and interoperability with other MOF-compliant tools.
The ODM metamodel for Topic Maps is similar to that specified in [TMDM], with named meta-associations, UML/MOF
compliant naming conventions, and a few additional abstract classes.
TopicMapConstruct
itemIdentifier : String [0..*]
Topic
ReifiableConstruct Reification TopicMapTopic
subjectLocator : String[0..1]
0..1 0..1 subjectItentifier : String [0..*] 0..*
+reifier +reified +topic
+parent
1
AssociationRole Occurrence TopicName Variant Association TopicMap
Topi cMapAssoci ation
value : String value : String value : String
0..* 1
datatype : String datatype : String +association +parent
Each Topic is about a single Subject. Subjects in TM may be anything physical or conceptual. A machine addressable
Subject will have a locator (e.g., a URL) while non-machine addressable subjects will have an identifier (e.g., the URL of
a page about the subject or a URN). Topics are roughly equivalent to RDF Resources, describing elements in a world of
discourse. Note that this similarity does not include RDF Literals that in TMs are not normally considered Topics.
13.1.1 TopicMapConstruct
Description
TopicMapConstructs are the abstract collection of elements that are part of any Topic Map. All first class elements are a
sub-type of Topic Map Construct and may optionally have a Source Locator.
Associations
None
Constraints
[1] It is an error for two different Topic Map Constructs to have source locators that are equal, expressed as the
following OCL:
context TopicMapConstruct inv:
TopicMapConstruct.allInstances()->
forAll(v_tmc1, v_tmc2 | v_tmc1.itemIdentifier->
forAll(v_sl1 | not(v_tmc2.itemIdentifier-> includes(v_sl1)))
)
Semantics
The itemIdentifier assigned to a TopicMapConstruct allows references to it. ItemIdentifiers may be freely assigned to
TopicMapConstructs based upon source syntax or other implementation defined methods.
13.1.2 ReifiableConstruct
Description
ReifiableConstruct defines an abstract class that groups together the kinds of topic map constructs that can be reified by
being associated with a topic. All constructs except Topic can be reified.
Attributes
None
Associations
• reified [0..1]: Topic in association Reification - relates the reifiable construct to the topic it reifies.
Constraints
None
Semantics
The act of reification is the act of making a topic represent the subject of another topic map construct in the same topic
map. For example, creating a topic that represents the relationship represented by an Association is reification.
13.1.3 TopicMap
Description
Attributes
None
Associations
• topic [0..*]: Topic in association TopicMapTopic – the set of Topics contained in this topic map.
• association [0..*]: Association in association TopicMapAssociation – the set of associations contained in this topic
map.
• Specialize class ReifiableConstruct
Constraints
None
Semantics
A TopicMap itself does not represent anything, and in particular has no subject associated with it. It has no significance
beyond its use as a container for Topics and Associations and the information about subjects they represent.
13.1.4 Topic
Description
Topic is the fundamental MapItem in a Topic Map. The class diagram for Topic is shown in Figure 13.2. Each Topic
represents a Subject in the domain of discourse.
0.. *
+variant
TopicNameVariant Name
Topic +parent
1
TopicTopicName TopicName
1 0..*
+parent +topicName
AssociationRole
TopicRole
1 0..*
+player +role 1..*
+role
RoleForAssociation
+parent
1
Association
Similar Terms
Attributes
• subjectLocator [0..1]: String – an optional resource reference that locates a machine addressable subject.
• subjectIdentifier [0..*]: String – the set of 0 or more resource references that identify a machine addressable indicator
of a non-machine addressable subject.
Associations
• occurrence [0..*]: Occurrence in association TopicOccurrence – the set of 0 or more occurrences for this Topic.
• parent [1]:TopicMap in association TopicMapTopic – the required TopicMap that this Topic is part of.
• reifier [0..1]: TopicMapConstruct in association Reification – a TopicMapConstruct may optionally be reified, becom-
ing the subject of a Topic. A TopicMapConstruct is reified if it is another Topic’s subjectIdentifier.
• role [0..*]: AssociationRole in association TopicRole – the collection of AssociationRoles that are the roles that this
Topic plays in Associations.
• scopedConstruct [0..*] : ScopeAble in association ScopeTopic - the set of 0 or more instaces of ScopeAble of which
this Topic is the scope.
• topicName [0..*]: TopicName in association TopicTopicName – the set of 0 or more topic names for this Topic.
• typedConstruct [0..*] : TypeAble in association TypeTopic - the set of 0 or more instaces of TypeAble of which this
Topic is the type.
Constraints
• All topics must have a value for at least one subject identifier or subject locator that is neither the empty set nor null,
expressed in the following OCL.
context Topic inv:
self.subjectIdentifier->notEmpty() or
self.subjectLocator->notEmpty()
Semantics
Each instance of Topic is associated with exactly one Subject. A subject indicator, subject identifier, or a subject locator
identifies that subject. The Topic Map Data Model defines these terms in part as:
• A subject indicator is an information resource that is referred to from a topic map in an attempt to unambiguously
identify the subject of a topic to a human being.
Topic maps contain only subject identifiers and subject locators, both of which refer to a subject indicator.
Topic is a very flexible concept. A topic can be a type whose instances are other topics, or associations, or association
roles, or occurrences, or topic names. But a topic can be outside any type system, or a type that is an instance can itself
be a type.
13.1.5 Association
Description
An Association is a multi-way relationship between one or more Topics. Associations must have a type and may be
defined for a specified scope.
Similar Terms
Relation, Property
Attributes
None
Associations
• parent[1]:TopicMap in association TopicMapAssociation – the required TopicMap that this Association is part of.
Constraints
None
Semantics
The relationship defined by an Association is a relationship among the included Topic’s subjects, rather than the Topics
themselves.
An association is an individual-level concept. Although an association must have a type, there is no constraint preventing
different instances of the same type having different association roles, or for an association role for different instances to
be linked to topics of different types, or no type at all.
13.2.1 ScopeAble
Description
ScopeAble defines an abstract class that provides the TM scoping mechanism. Subclasses of ScopeAble may have a
defined scope of applicability.
Similar Terms
Attributes
None
Associations
• scope[0..*]: Topic in association ScopeTopic – the topics that define the scope.
Constraints
None
Semantics
If the scope association is empty, then the ScopeAble items have the default scope.
TypeAble defines an abstract class that provides the typing mechanism. Subclasses of TypeAble must define types.
Elements in TM are singly typed. A typed construct is an instance of its type. Type describes the nature of the represented
construct.
Similar Terms
Attributes
None
Associations
• type [1..1]: Topic in association TypeTopic – the required topic which defines at most a single type.
Constraints
None
Semantics
13.2.3 AssociationRole
Description
An Association is composed of a collection of roles, which are played by Topics. The AssociationRole captures this
relation. A Topic in an Association plays a particular part or role in the Association. This is specified in an Association
Role. The Association and Association Role construct is similar to a UML Association or to an RDF Property.
Similar Terms
Role, UML Association End, UML Property
Attributes
None
Associations
• parent[1]: Association in association RoleFor Association – the required Association which the AssociationRole is part
of.
• player[1]: Topic in association TopicRole – the required Topic that plays this role in the parent Association.
None
Semantics
An AssociationRole is the representation of the participation of subjects in an association. The association role has a topic
playing the role and a type that defines the nature of the participation of the player in the association. The roles and
associations are representing the relationships between the participating Topic’s subject, rather than the topics themselves.
13.2.4 Occurrence
Description
Similar Terms
Attribute, Slot
Attributes
• value[1]:String – If the datatype is IRI, a locator referring to the information resource the occurrence connects with the
subject, otherwise the string is the information resource.
Associations
• parent[1] : Topic in association TopicOccurrence - the required Topic which owns the Occurrence.
Constraints
None
Semantics
It may be mistakenly inferred by the name ‘Occurrence’ that this construct refers only to instances of a Topic. This is not
the case. An Occurrence may be any descriptive information about a Topic, including instances, and may represent any
characteristic of a Topic, including an ‘occurrence’ or instance of the subject. Occurrences are semantically similar to
UML Attributes.
Variant
0..*
+scopedVariant
VscopeTop ic
+s cope
1..*
TypeAble TypeTopic Topic ScopeTopic ScopeAble
0..* 1 0..* 0..*
+typedConstruct +type +scope +scopedConstruct
13.2.5 TopicName
Description
Similar Terms
Attributes
• value: String [1] – the Base Name for this Topic; the string is UNICODE.
Associations
• variant [0..*]: VariantName in association TopicNameVariantName – Zero or more variations of the TopicName.
Constraints
None
Semantics
The term ‘name’ should not be misconstrued to imply uniqueness. Neither the topic name, nor its variants, are identifying;
they serve only as human readable labels.
Variant allows alternative names for a Topic to be specified. These names may be any format, including text, documents,
images, or icons. Variants must have scope.
Similar Terms
Attributes
• value[1]:String – If the datatype is IRI, a locator referring to the information resource the occurrence connects with the
subject, otherwise the string is the information resource.
Associations
• scope[1..*] : Topic in association VscopeTopic – one or more topics that define the scope.
Constraints
• A Variant is restricted to being a composite part of a TopicName. It cannot exist as a standalone construct as con-
strained by the TopicNameVariantName association multiplicity.
Semantics
• Types and Instance –Types and their instances are related by three subjects representing the type-instance association
and the type and instance association roles. A type is an abstraction that captures characteristics common to a set of
instances. A type may itself be an instance of another type, and the type-instance relationship is not transitive.
• Super and Sub Types – Types may be arranged into a type hierarchy using the supertype-subtype association and,
supertype and subtype association roles. The supertype-subtype relationship is the relationship between a more general
type (the supertype) and a specialization of that type (the subtype). The supertype-subtype relationship is transitive.
• Special Variant Names – Display and Sort are two special types of variant names appropriate for human display and
sorting.
• Topic Map Constructs –Subjects that represent the reification of topic map constructs such as association, associations-
role, or occurrence.
:Topic
subjectIdentifier = 'tmcore:type'
inst:Topic
type
player
:AssociationRole :Association
role role parent
parent
:Topic
subjectIdentifier = 'tmcore:type-instance' type
:Topic
subjectIdentifier = 'tmcore:instance'
type:Topic
player type
:AssociationRole
role role
:Topic
subjectIdentifier = 'tmcore:subType'
type
role
subt:Topic player :AssociationRole :Association
role parent
parent
supert:Topic :AssociationRole
player role role
type
:Topic
subjectIdentifier = 'tmcore:superType'
type
:Topic
subjectIdentifier = 'tmcore:superType-subType'
In a similar way, that two topics are in a subtype-supertype relationship is declared by an association with two roles, the
association and both roles of types taken from the published subjects, as in Figure 13.5. The instance of Topic labeled
‘subt’ is declared as a subtype of the instance of Topic labeled ‘supert.’
13.4 Example
Figure 13.6 depicts a simple instance model of the TM meta-model. The model depicted represents the following
statements:
type
ColorOf:Topic isColor:Topic Owned:Topic Owner:Topic
Color:Topic Person:Topic
type type
Red:Topic CarlsRedCar:Topic Carl:Topic
This profile is based on the UML Kernel package defined in “Unified Modeling Language: Superstructure,” version 2
[UML2] as well as on the Profiles section of the same document. It is designed to support modelers developing
vocabularies in RDF and richer ontologies in the Web Ontology Language (OWL) through reuse of UML notation using
tools that support UML2 extension mechanisms. The profile:
• Reuses UML constructs when they have the same semantics as OWL, or, when this is not possible, stereotypes UML
constructs that are consistent and as close as possible to OWL semantics.
• Uses standard UML 2 notation, or, in the few cases where this is not possible, follows the clarifications and
elaborations of stereotype notation defined in UML 2.1 (See [UML2.1], Profiles chapter).
The profile has been partitioned to support users who wish to restrict their vocabularies to RDF/S, as well as to reflect the
structure of the RDF and OWL metamodels (and the languages themselves). It leverages stereotypes extensively and uses
stereotype properties in traditional fashion. It complements the metamodels defined in Chapter 10, and in Chapter 11,
respectively, for overall structure, semantics and language mapping. It also depends on model elements included in
Annex A, for certain basic definitions, such as the M1 level elements discussed in Chapter 8, Design Rationale.
The following sections specify the set of stereotypes that comprise the UML2 profile for using UML to represent RDF/S
vocabularies. It is designed to support all of RDF, as reflected in the RDF metamodel (Base, RDFS, and Web, together)
provided in Chapter 10, with minor limitations, is based on the presumption that vendors (and users) are interested in
developing RDF vocabularies that make use of the schema elements of the language in the context of the Web. The
document related elements are recommended as a basis for exchanging namespace information, at a minimum, even in
cases where a document representation is not required.
<<profile>>
RDF
(from org.omg.odm)
Constraints
[1] All classes in a package stereotyped by «rdfDocument» must be stereotyped by «rdfsClass» (or an appropriate
subclass, such as «owlClass»).
Description
A namespace is declared using a family of reserved attributes. These attributes, like any other XML attributes, may be
provided directly or by default. Some names in XML documents (constructs corresponding to the non-terminal Name)
may be given as qualified names. The prefix provides the namespace prefix part of the qualified name, and must be
associated with a namespace URI in a namespace declaration.
Parent
None
Properties
Constraints
[1] The string value of namespacePrefix must conform to the specification given in [XMLNS].
[2] The string value of the namespace URI must conform to the character encoding (including escape sequences and
so forth) defined in [RDF Syntax] and [XMLNS].
14.1.2.2 RDFDocument
Description
An RDF document represents the primary namespace mechanism / container for an RDF/S vocabulary. The ordered set of
definitions (statements) that comprise an RDF vocabulary are contained in a document. This set of statements may also
correspond to one or more graphs contained in the document.
Note that this approach supports RDF graphs that span multiple documents, and enables multiple graphs to occur within
a particular document (although it is more natural from a UML modeling perspective to assume that there is a 1-1
mapping between a graph and a document).
Parent
None
Properties
RDF namespace declarations are associated with the RDF document that acts as the container for the set of RDF graphs
that make up the vocabulary or ontology component, rather than with the optional ontology header definition (in the case
of an OWL ontology) or other statements.
• xmlBase: String [0..*] – provides zero or more base namespaces used in the document.
• namespaceDefinition: NamespaceDefinition [0..*] – defines zero or more namespace definitions used in the document.
• statementForDocument: InstanceSpecification [1..*] {ordered} – the set of statements in the document.
Constraints
[1] Either defaultNamespace must be present or at least one xmlBase must be specified. (An «rdfDocument» must have
an IRI/URI.)
[2] The string value for any defaultNamespace property must conform to the character encoding (including escape
sequences and so forth) defined in defined in [RDF Syntax] and [XMLNS].
[3] The string value for any xmlBase property must conform to the character encoding (including escape sequences
and so forth) defined in defined in [RDF Syntax] and [XMLNS].
[4] The classifier of the InstanceSpecification(s) for the statements in a document must be RDFStatement.
14.1.2.3 UniformResourceIdentifier
Description
The RDF abstract syntax is concerned primarily with URI references. This definition of a URI and related stereotype,
distinct from URI reference, is included primarily for mapping purposes (i.e., mapping across RDF vocabularies and
OWL ontologies, as well as among the paradigms covered in this specification). The distinction between a URI and URI
reference is covered more thoroughly in Chapter 10. Also, see [RDF Syntax] for further definition detail.
Note that URIs and IRI/URI references specified using this RDF profile are globally defined, in contrast to naming and
namespace conventions in UML2, which can be limited to the package level or to a set of nested namespaces.
Parent
None
Properties
None
Constraints
[1] The string value for the «uniformResourceIdentifier» must conform to the character encoding (including escape
sequences and so forth) defined in defined in [RDF Syntax] and [XMLNS].
[2] The string value for the «uniformResourceIdentifier» must be present (i.e., the IRI/URI).
14.1.2.4 URIReference
Description
RDF uses URI references to identify resources and properties. A URI reference within an RDF graph (an RDF URI
reference) is a Unicode string conforming to the characteristics defined in [RDF Concepts] and [RDF Syntax].
• given as XML attribute values interpreted as relative URI references that are resolved against the in-scope base URI to
give absolute RDF URI references.
Parent
None
Properties
Constraints
[1] The string value of the «uriReference» must conform to the constraints defined in [RDF Syntax] and [XMLNS].
[2] The value of the uri property must be a UML::LiteralString that is stereotyped by «uniformResourceIdentifier».
[3] (Semantic) The string value of the «uriReference» corresponds to the optional fragment identifier of the IRI/URI.
14.1.3.1 BlankNode
Description
A blank node is a node that is not a URI reference or a literal. In the RDF abstract syntax, a blank node is simply a unique
node that can be used in one or more RDF statements, but has no intrinsic name. Blank nodes are an integral part of the
RDF language, and are used extensively in OWL class descriptions. In practice in a UML tool environment, it is likely
that they will be needed when reverse engineering RDF vocabularies and OWL ontologies, and most importantly for
coreference resolution when mapping across ontologies.
Parent
«rdfsResource»
Properties
14.1.3.2 RDFGraph
Description
An RDF graph is the container for the set of statements (subject, predicate, object subgraphs) in an RDF/S vocabulary. In
UML this container is a package. This definition of a graph is included in the profile to support identification /
componentization of RDF vocabularies through the use of named graphs, and for vocabulary mapping purposes.
Parent
None
Properties
• graphName: LiteralString [0..1] – the optional URI reference naming the graph.
• statementForGraph: InstanceSpecification [1..*] – the set of statements in the graph.
Constraints
[1] The string value of the graphName property must be a UML::LiteralString that is stereotyped by «uriReference».
[2] The value of any statementForGraph property must be a UML::InstanceSpecification classified by RDFStatement,
and may have the «rdfsResource» stereotype applied.
14.1.3.3 RDFSLiteral
Description
Literals are used to identify values such as numbers and dates by means of a lexical representation. Anything represented
by a literal could also be represented by a URI, but it is often more convenient or intuitive to use literals.
A literal may be the object of an RDF statement, but not the subject or the predicate.
Literals may be plain or typed. The string value associated with an «rdfsLiteral» corresponds to its lexical form.
Parent
None
Properties
None
14.1.3.4 RDFSResource
Description
The uriRef property is used to uniquely identify an RDF resource globally. Note that this property has a multiplicity of
[0..*] that provides for the possibility of the absence of an identifier, as in the case of blank nodes, and the possibility of
multiple identifiers.
A particular resource may be identified by more than one URI reference, and may be reified by another resource (see
«reifies», below).
Parent
None
Properties
• memberOf: LiteralString [0..*] – a URI reference(s) relating a particular resource to another in terms of membership
(i.e., in a class or container).
Constraints
[1] The string value(s) of the uriRef property must be a UML::LiteralString that is stereotyped by «uriReference».
[2] The string value(s) of the memberOf property must be a UML::LiteralString that is stereotyped by «uriReference».
14.1.3.5 RDFStatement
Description
An RDF triple contains three components:
An RDF triple is conventionally written in the order subject, predicate, object. The relationship represented by the
predicate is also known as the property of the triple. The direction of the arc is significant: it always points toward the
object.
None
Properties
• reification: ReificationKind [1] – indicates whether or not a particular statement (triple) is reified but not asserted,
reified, or neither; default value is “none.”
• subject: InstanceSpecification [0..1] – the resource that is the subject of the statement.
• object: InstanceSpecification [0..1] – the resource that is the object of the statement.
Constraints
[1] The value of the subject property must be a UML::InstanceSpecification that is classified by «uriReferenceNode» or
«blankNode».
[2] The value of the predicate property must be a UML::AssociationClass that is classified by «rdfProperty».
[3] The value of the object property must be a UML::InstanceSpecification that is classified by «rdfsResource».
[4] If the value of the reification property is “reified,” then the subject, predicate, and object must be filled.
14.1.3.6 Reification
Description
A particular resource may be identified by more than one URI/IRI reference, and may be reified by another resource,
represented by a dependency between instance specifications (resources) stereotyped by «reifies».
Parent
None
Properties
None
Constraints
[1] The «reifies» stereotype can only be applied to a UML::Dependency that links two UML::InstanceSpecifications
that are stereotyped by «rdfsResource». The dependency must be navigable from the reifying resource to the
resource it reifies.
14.1.3.7 URIReferenceNode
Description
A URI reference or literal used as a node identifies what that node represents. URIReferenceNode is included in order to
more precisely model the intended semantics (i.e., not all URI references are nodes). A URI reference used as a predicate
identifies a relationship between the things represented by the nodes it connects. A predicate URI reference may also be
a node in the graph.
Parent
«rdfsResource»
Properties
None
Constraints
[1] The uriRef property, inherited from «rdfsResource», must have a value.
[2] The string value of the uriRef property must be a UML::LiteralString that is stereotyped by «uriReference».
[3] An InstanceSpecification cannot be stereotyped by «blankNode» and «uriReferenceNode» at the same time.
14.1.4 ReificationKind
Description
ReificationKind is an enumerated type used by the reification property on RDFStatement. It has three possible values:
none (which is the default value), reified (meaning that the statement is both asserted and reified), and reifiedOnly
(meaning that a statement is reified but not asserted - providing a placeholder in a UML model representing an RDF
vocabulary for such a statement, which is necessary when we want to say things about statements that occur in some
external vocabulary that are not available to this model).
Parent
None
Properties
None
Constraints
[1] ReificationKind has three possible values: ‘none,’ ‘reified,’ and ‘reifiedOnly.’
[2] The default value of ReificationKind is ‘none.’
14.1.5 Literals
The stereotypes associated with the definitions given in “RDFBase Package, RDF Literals” on page 41, in addition to
those given above, are defined in this section.
Description
A plain literal is a string combined with an optional language tag. This may be used for plain text in a natural language.
Plain literals are self-denoting.
Parent
«rdfsLiteral»
Properties
Constraints
[1] A LiteralString cannot be stereotyped by «plainLiteral» and «typedLiteral» at the same time.
[2] The string value of the language property, if present, must conform to the syntax and encoding specified in
[RFC3066].
14.1.5.2 RDFSComment
Description
A comment is a plain literal, contained by the resource it describes, and can be applied to any resource. Because it seems
natural from a UML perspective to use a UML Comment for this feature, rather than inheriting or having a relationship
with «plainLiteral», we’ve added a property to Comment to optionally support language tags.
Parent
None
Properties
Constraints
[1] The string value of the language property, if present, must conform to the syntax and encoding specified in
[RFC3066].
14.1.5.3 RDFSLabel
Description
A label is a plain literal, contained by the resource it describes, and provides a human-readable label, or “pretty name”
that can be applied to any resource.
Parent
«plainLiteral»
Properties
None
Constraints
No additional constraints
14.1.5.4 RDFXMLLiteral
Description
rdf:XMLLiteral is a predefined RDF datatype used specifically for encoding XML in an RDF document. The value of
the datatypeURI property must correspond to the URI for rdf:XMLLiteral.
Parent
«typedLiteral»
Properties
None
Constraints
[1] The value of the datatypeURI property must be the IRI/URI for rdf:XMLLiteral.
14.1.5.5 TypedLiteral
Description
Typed literals have a lexical form, which is a Unicode string, and a datatype URI being an RDF URI reference.
The datatype URI refers to a datatype. For XML Schema built-in datatypes, URIs such as http://www.w3.org/2001/
XMLSchema#integer are used. The URI of the datatype rdf:XMLLiteral may be used. There may be other,
implementation dependent, mechanisms by which URIs refer to datatypes.
The value associated with a typed literal is found by applying the lexical-to-value mapping associated with the datatype
URI to the lexical form. If the lexical form is not in the lexical space of the datatype associated with the datatype URI,
then no literal value can be associated with the typed literal. Such a case, while semantically in error, is syntactically well-
formed.
«rdfsLiteral»
Properties
• datatypeURI: LiteralString [1] – specifies the URI for the datatype specification that defines its type (of which it is an
instance).
Constraints
[1] A typed literal must have a value for the datatypeURI property.
[2] The string value of the datatypeURI property must be a UML::LiteralString that is stereotyped by «uriReference».
[3] For built-in datatypes (i.e., those that are not user-defined), the string value of the datatypeURI must be that of an
XML Schema Datatype as defined in [XML Schema Datatypes], and as given in Annex A.
[4] A LiteralString cannot be stereotyped by «plainLiteral» and «typedLiteral» at the same time.
[5] (Semantic) The value of the datatypeURI property must match a URI corresponding to a datatype definition of the
appropriate type.
14.1.6.1 RDFSClass
Description
The collection of resources that represents RDF Schema classes is itself a class, called rdfs:Class. Classes provide an
abstraction mechanism for grouping resources with similar characteristics. The members of a class are known as instances
of the class. Classes are resources. They are often identified by RDF URI References and may be described using RDF
properties.
An RDFS class maps closely to the UML definition of a class; one notable exception is that an RDFS class may have a
URI reference. The definition of the «rdfsClass» stereotype corresponds to “RDFSClass” on page 48.
Parent
None
Properties
Constraints
[1] The value of the uriRef property must be a UML::LiteralString that is stereotyped by «uriReference».
Description
rdfs:Datatype represents the class of datatypes in RDF. Instances of rdfs:Datatype correspond to the RDF model of
a datatype described in the RDF Concepts specification [RDF Concepts]. Note that built-in instances of rdfs:Datatype
correspond to the subset of datatypes (defined in [XML Schema Datatypes]) allowable for use in RDF, as specified in
[RDF Concepts]. These are provided for use with the metamodel(s) and profile(s) in the model library given in Annex A
(“Foundation Library (M1) for RDF and OWL”). Use of user-defined datatypes should be carefully considered against
any desire for reasoning over an RDF vocabulary, OWL ontology, or knowledge base.
Parent
None
Properties
• uriRef: LiteralString [1..*] – the URI reference(s) associated with the datatype.
Constraints
[1] The value of the uriRef property must be a UML::LiteralString that is stereotyped by «uriReference».
[2] For built-in datatypes (i.e., those that are not user-defined), the string value of the uriRef must be that of an XML
Schema Datatype as defined in [XML Schema Datatypes], and as given in Annex A.
[3] (Semantic) The value of the uriRef property must link the «rdfsDatatype» to either an XML Schema Datatype or
user-defined type corresponding to a datatype definition of the appropriate type.
14.1.6.3 RDFSisDefinedBy
Description
rdfs:isDefinedBy provides a means to indicate that a particular resource (the source, or owning classifier) is defined by
another resource (the target resource). Note that RDF does not constrain the usage of rdfs:isDefinedBy, though in
practice, vocabularies that use this construct, such as the Dublin Core, will do so.
Parent
«rdfsSeeAlso»
Properties
None
Constraints
[1] (Semantic) The «rdfsIsDefinedBy» stereotype is used to state that a particular resource (the subject of the RDF
statement) is defined by another resource (the object of the RDF statement). In theory, this stereotype can be applied
14.1.6.4 RDFSseeAlso
Description
rdfs:seeAlso indicates that more information about a particular resource (the source, or owning classifier) can be
found at the target resource.
Parent
None
Properties
None
Constraints
[1] (Semantic) The «rdfsSeeAlso» stereotype is used to state that additional information about a particular resource (the
subject of the RDF statement) is given by another resource (the object of the RDF statement). As with
«rdfsIsDefinedBy», this stereotype can be applied to a dependency between any two “generic” resources, but in
practice, we recommend that it is applied to a UML::Dependency that links two UML::InstanceSpecifications that
are stereotyped by «rdfsResource».
14.1.6.5 RDFSsubClassOf
Description
rdfs:subClassOf indicates that the resource is a subclass of the general class; it has the semantics of UML
Generalization. However, classes on both ends of the generalization must be stereotyped «rdfsClass», or «owlClass», if
used with the profile for OWL.
Note in OWL DL that mixing inheritance among RDFS and OWL classes is permitted, as long as proper subclassing
semantics is maintained. In order for a model to be well formed an OWL class can be a subclass of an RDFS class but not
vice versa. In other words for OWL DL, once you're in OWL you need to stay there.
Parent
None
Properties
None
14.1.6.6 RDFType
Description
rdf:type maps to the relation between instance and classifier in UML. This can be represented in a UML model by the
relation between an instance specification and its classifiers. For M1, rdf:type maps to the classifier association
between an instance specification and classifiers in UML. Note that resources in RDF can be multiply classified. No
stereotype is needed.
Description
A property in UML can be defined as part of an association or not. When it is not part of an association, the property is
owned by the class that defines its domain, and the type of the property is the class that defines its range. When a property
is part of an association, the association is binary, with the class that defines the domain of the property owning that property.
Properties in RDF and OWL are defined globally, that is, they are available to all classes in all vocabularies and
ontologies – not only to classes in the vocabulary or ontology they are defined in, but to classes in other vocabularies and
ontologies, including those that are imported. For RDF properties that are defined without specifying a domain or range,
the profile uses an anonymous class (analogous to owl:Thing in OWL ontologies) for the “missing” end class.
Parent
None
Properties
Constraints
[1] The value of the uriRef property must be a UML::LiteralString that is stereotyped by «uriReference».
[2] Association classes with «rdfProperty» applied are binary, and have unidirectional navigation (i.e., explicitly from
the class that defines its domain to the class that defines its range, in other words from the class that owns it to its
type).
[3] Properties cannot have the same value twice (i.e., in UML, isUnique=true).
[4] Property values are not ordered (i.e., in UML, isOrdered=false).
There are several alternatives for representing various aspects of RDF properties in UML, as follows.
A. Properties without a specified domain or range may be represented using a stereotyped class, as shown in Figure
14.2.
B. Properties without a specified domain are considered to be defined on an anonymous class, (or possibly on
owl:Thing in the case of an OWL ontology), for example, as shown in Figure 14.3.
h a s C o lo r : C o lo r
From a UML perspective, properties are semantically equivalent to binary associations with unidirectional navigation
(“one-way” associations).
<<rdfsClass>> <<rdfsClass>>
+hasColor
Color
<<rdfProperty>>
Figure 14.4 shows that there is efficient navigation from an instance of an anonymous class to an instance of Color
through the hasColor end, just like a UML property. The only difference from a property on the anonymous class is that
the underlying repository will have an association with the hasColor property as one of its ends. The other end will be
owned by the association itself, and be marked as non-navigable.
<<rdfProperty>>
Ha sCo lor
Figure 14.5 - Property hasColor Without Specified Domain - Association Class Representation
An association class can have properties, associations, and participate in generalization as any other class. Notice that the
association has a (slightly) different name than the property, by capitalizing the first letter, to distinguish the association
class (of links, tuples) from the mapping (across those links, tuples). A stereotype «rdfProperty» is introduced to highlight
such binary, unidirectional association classes, as shown in Figure 14.5. In the examples given in the remainder of the
profile, the notation showing properties in class rectangles is sometimes used, but unidirectional associations and
association classes could be used instead.
A stereotype indicating that the association between the hasColor property and Color class representing the RDF range
restriction is introduced here and defined in Section 14.1.7.4.
C. Properties with a domain are defined on a UML class for the domain, where the property is not inherited from a
supertype.
<<rdfProperty>>
Chases
Normally UML models introduce properties and restrict them with multiplicities in the same class. This translates to
RDF/OWL as global properties of an anonymous class (or possibly to owl:Thing in OWL, and to restrictions on
subclasses of owl:Thing). An optional stereotype «rdfGlobal» is introduced to highlight properties on the class where
they are introduced, which will translate to global properties in OWL. Properties that are inherited are distinguished in
UML by subsetting or redefinition, as discussed below.
Figure 14.8 - Property hasColor With Specified Domain and Range, Class Notation
One option for property subsetting in UML is to use “{subsets <super-property-name>}” at the end of the property entry
in a class, as shown in Figure 14.9.
Alternatively, the representation given in Figure 14.10 may be used for unidirectional association subsetting.
For use with association classes, the representation shown in Figure 14.11, which uses a UML Generalization with the
stereotype «rdfsSubPropertyOf», is preferred. Note that «rdfsSubPropertyOf» may not be required – it does not change
the semantics, only adds constraints on its own usage.
<<rdfsSubPropertyOf>>
<<rdfProperty>>
Chases
<<rdfProperty>> +follows
<<rdfsClass>> <<rdfsClass>>
Dog
<<rdfProperty>>
+chases
Figure 14.12 provides another example of RDFS property subtyping, in this case using UML classes to represent the
relevant RDF properties.
14.1.7.2 RDFGlobalProperty
Description
An optional stereotype on a unidirectional association class, class, or property with «rdfProperty» applied, indicating the
association/class property is defined globally, i.e., that class having the property, or on the non-navigable end of the
association, is the class on which the class property/association is introduced, i.e., the property is not inherited from a
superclass.
Parent
«rdfProperty»
None
Constraints
[1] The property being stereotyped must be on an anonymous class (or possibly on an instance of owl:Thing in
OWL), or on an association class for a unidirectional association that has an anonymous class on the non-navigable
end.
14.1.7.3 RDFSDomain
Description
rdfs:domain indicates that RDF resources denoted by the subjects of triples whose predicate is a given property P are
instances of the class denoted by the domain. When a property has multiple domains, then the resources denoted by the
subjects of triples whose predicate is P are instances of all of the classes stated by the rdfs:domain properties (In OWL,
this is typically thought of as an anonymous class representing the intersection of all of the classes said to be in the
domain of the property).
Parent
None
Properties
None
Constraints
[1] Applies only to associations between a class with an «rdfsClass» stereotype applied (or any of its children, e.g.,
«owlClass»), and a class with «rdfProperty» applied.
[2] Associations with «rdfsDomain» applied are binary.
[3] Associations with «rdfsDomain» applied have unidirectional navigation (from the class with the «rdfProperty»
stereotype applied to the class with the «rdfsClass» stereotype applied).
Graphical Notation
Figure 14.13 - «rdfsDomain» Stereotype Notation - Class Notation for RDF Property
Description
rdfs:range indicates that the values of a given property P are instances of the class denoted by the range. When a
property has multiple rdfs:range properties, then the resources denoted by the objects of triples whose predicate is P
are instances of all of the classes stated by the rdfs:range properties. (In OWL, this is typically thought of as an
anonymous class representing the intersection of all of the range classes.)
Parent
None
Properties
None
Constraints
[1] Applies only to associations between a class with an «rdfsClass» stereotype applied (or any of its children, e.g.,
«owlClass»), and a class with «rdfProperty» applied.
[2] Associations with «rdfsRange» applied are binary.
[3] Associations with «rdfsRange» applied have unidirectional navigation (from the class with the «rdfProperty»
stereotype applied to the class with the «rdfsClass» stereotype applied).
Graphical Notation
Figure 14.14 - «rdfsRange» Stereotype Notation - Class Notation for RDF Property
14.1.7.5 RDFSsubPropertyOf
Description
rdfs:subPropertyOf is used to specialize RDF properties, similar to class generalization/specialization, and indicates
that all the instances of the extension of the subproperty are instances of the extension of the super property. See above for
further discussion and representation options, if used.
Parent
None
None
Constraints
[1] Association classes on both ends of the generalization must be stereotyped «rdfProperty» or «objectProperty» or
«datatypeProperty», if used with the profile for OWL.
[2] In OWL DL, an association class stereotyped by «objectProperty» or «datatypeProperty» may specialize a class
stereotyped by «rdfProperty», but not vice versa.
Im p o rt s
An OWL ontology consists of zero or more optional ontology headers (typically at most one), which may include a set of
ontology properties, such as owl:Imports statements, plus any number of class axioms, property axioms, and facts about
individuals.
Parent
«rdfDocument»
Properties
None
Constraints
[1] All classes (except association classes) in a package stereotyped by «owlOntology» must be stereotyped by
«rdfsClass» or by «owlClass» (or an appropriate subclass).
[2] For applications intending to support OWL DL, all classes (except association classes) in a package stereotyped by
«owlOntology» must be stereotyped by «owlClass» (or one of its subclasses).
14.2.3.1 OWLAnnotationProperty
Description
«owlAnnotation» represents the class of user-defined annotation properties in OWL (corresponding roughly to
“OWLAnnotationProperty” on page 81. OWL annotations can be applied to any ontology element (e.g., ontologies,
classes, properties, individuals).
Parent
«rdfProperty»
Properties
None
Constraints
None
Description
An owl:versionInfo property generally has a string that provides information about the version of the element to
which it is applied, for example RCS/CVS keywords. It does not contribute to the logical meaning of the ontology other
than that given by the RDF(S) model theory.
Although typically used to make statements about ontologies, it may be applied to instance of any OWL construct. For
example, one could apply an owl:versionInfo property to a class stereotyped by «owlClass», or to an instance of the
RDFStatement class.
No stereotype; implemented as a UML Property of the stereotype or model library class it describes.
Parent
None
Properties
None
Constraints
None
Graphical Representation
In the case of an ontology, with a package stereotyped by «owlOntology» or «rdfDocument», the normal stereotype
notation can be used, with property values specified in braces under the stereotype label4, as shown in Figure 14.16.
4. The stereotype property follows the clarifications and elaborations of stereotype notation defined in Unified Modeling Language:
(UML) Superstructure, Profiles chapter, http://www.omg.org/spec/UML..
14.2.4.1 owl:OntologyProperty
Description
owl:OntologyProperty represents the class of ontology properties in OWL, both built-in and user defined,
corresponding to Section 11.4.6, “OWLOntologyProperty.”
User-defined ontology properties are properties defined on the «owlOntology» or «rdfDocument» stereotypes, that can
apply only between packages having these stereotypes.
Parent
None
Properties
None
Constraints
[1] Applies only to properties of «owlOntology» or «rdfDocument».
[2] Types of properties stereotyped by «owlOntologyProperty» must be stereotyped by «owlOntology» or
«rdfDocument».
14.2.4.2 owl:backwardCompatibleWith
Description
owl:backwardCompatibleWith refers to another ontology, and identifies the specified ontology as a prior version, and
further indicates that it is backward compatible with it.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between packages stereotyped by «owlOntology» or «rdfDocument».
[2] Classes and properties in the new version that have the same name as classes and properties in the earlier version
must either be equivalent to or extend those in the earlier versions.
Graphical Representation
Dashed line between two instances with stereotype label, arrowhead towards the earlier version, as shown in Figure
14.17.
<<rdfDocument>> <<rdfDocument>>
{ versionInfo = "1. 2" } <<backwardCompatibleWith>> { versionInfo = "1.1" }
MyNewOntology MyOntology
14.2.4.3 owl:imports
Description
owl:imports references another OWL ontology containing definitions, whose meaning is considered to be part of the
meaning of the importing ontology. Each reference consists of a URI specifying from where the ontology is to be
imported.
Parent
None
Properties
None
Constraints
[1] Applies only to imports between packages stereotyped by «owlOntology» or «rdfDocument».
Graphical Representation
Dashed line between two instances with stereotype label, arrowhead towards the imported ontology, as shown in Figure
14.18.
14.2.4.4 owl:incompatibleWith
Description
owl:incompatibleWith indicates that the containing ontology is a later version of the referenced ontology, but is not
necessarily backward compatible with it. Essentially, this allows ontology authors to specify that a document cannot be
upgraded without verifying consistency with the specified ontology.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between packages stereotyped by «owlOntology» or «rdfDocument».
Graphical Representation
Dashed line between two instances with stereotype label, arrowhead towards the earlier version, as shown in Figure
14.19.
<<rdfDocument>> <<rdfDocument>>
{ versionInfo = "1. 2" } <<incom pat ibleWith>> { versionInfo = "1.1" }
MyNewOntology MyOntology
14.2.4.5 owl:priorVersion
Description
owl:priorVersion identifies the specified ontology as a prior version of the containing ontology. This has no meaning
in the model-theoretic semantics other than that given by the RDF(S) model theory. However, it may be used by software
to organize ontologies by versions.
Because of the lack of semantics, there is no obvious UML element to reuse or stereotype for this particular OWL
property. However, assuming that the spirit of this property is similar to though not quite as strong as that of
«backwardCompatibleWith», the same base class is used.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between packages stereotyped by «owlOntology» or «rdfDocument».
Graphical Representation
Dashed line between two instances with stereotype label, arrowhead towards the earlier version, as shown in Figure
14.20.
<<rdfDocument>> <<rdfDocument>>
{ versionInfo = "1.2" } <<priorVersion>> { versionInfo = "1.1" }
MyNewOntology MyOntology
A class description is the term used in [OWL S&AS] for the basic building blocks of class axioms. A class description
describes an OWL class, either by a class name or by specifying the class extension of an unnamed anonymous class.
3. a property restriction
The first type is special in the sense that it describes a class through a class name (syntactically represented as a URI
reference). The other five types of class descriptions typically describe an anonymous class by placing constraints on the
class extension. They consist of a set of RDF triples in which a blank node represents the class being described. This
blank node has a type property whose value is «owlClass». Note that multiple class descriptions can be applied to the
same class, however, such that these anonymous classes can ultimately also be named.
Class descriptions of type 2-6 describe, respectively, a class that contains exactly the enumerated individuals (2nd type),
a class of all individuals that satisfy a particular property restriction (3rd type), or a class that satisfies boolean
combinations of class descriptions (4th, 5th, and 6th type). Intersection, union, and complement can be respectively seen
as the logical AND, OR, and NOT operators. The four latter types of class descriptions lead to nested class descriptions
and can thus in theory lead to arbitrarily complex class descriptions. In practice, the level of nesting is usually limited.
Stereotypes for OWL class descriptions are given below.
14.2.5.1 OWLClass
Description
owl:Class describes a class through a class name, and corresponds to 11.3.5 (“OWLClass”).
Note: owl:Class is defined as a subclass of rdfs:Class. The rationale for having a separate OWL class construct lies
in the restrictions on OWL DL (and thus also on OWL Lite), which imply that not all RDFS classes are legal OWL DL
classes. In OWL Full these restrictions do not exist and therefore owl:Class and rdfs:Class are equivalent in OWL
Full.
«rdfsClass»
Properties
• isDeprecated: Boolean [0..1] – provides an additional annotation that indicates a particular class definition is
deprecated.
Constraints
None
14.2.5.2 EnumeratedClass
Description
«enumeratedClass» describes a class by enumerating the set of individuals, or UML instance specifications, that are
members of the class, and corresponds to Section 11.3.2, “EnumeratedClass.”
Parent
«owlClass»
Properties
• isComplete: Boolean [0..1] – indicates whether the set of enumerated individuals is complete, meaning, that this
provides a complete specification for the class.
Constraints
None
14.2.5.3 RestrictionClass
Description
owl:Restriction reifies a special kind of class. The restriction class is a subtype of the domain of the restricted
property, and identifies a class specifying exactly the necessary and sufficient conditions that make a particular individual
a member of that class. It describes an anonymous class, namely a class of all individuals that satisfy the restriction. It can
be used with other classes in a number of ways, and when paired with exactly one other class, will be either a supertype,
a subtype, or equivalent (necessary, sufficient, or both). When used in another class, the restriction class is effectively a
supertype of the containing class, applying the restriction to all individuals of the containing class.
OWL distinguishes two kinds of property restrictions: value constraints and cardinality constraints. Property restrictions
can be applied both to datatype properties (properties for which the value is a data literal) and object properties
(properties for which the value is an individual).
Note: Although restriction classes are typically anonymous, they are not required to be and can be named (via a class ID
URI reference/name).
Parent
«owlClass»
Properties
• onProperty: Property [1] – identifies the property to which the restriction applies.
Constraints
[1] (Semantic) Instances of the class are all and only those instances satisfying the restriction.
Description
In OWL, like in RDF, it is assumed that any instance of a class may have an arbitrary number (zero or more) of values
for a particular property. To make a property required (at least one), to allow only a specific number of values for that
property, or to insist that a property must not occur, cardinality constraints can be used. OWL provides three constructs
for restricting the cardinality of properties locally within a class context: owl:maxCardinality, owl:minCardinality, and
owl:Cardinality. These constructs are analogous to multiplicity in UML, thus the approach taken is for:
• Properties whose initial definition includes the cardinality constraint - simply apply multiplicities as appropriate.
None. UML multiplicities are presented using the standard presentation options defined in section 7.3.32, “Unified
Modeling Language: Superstructure,” version 2 [UML2].
Parent
None
Properties
None
Constraints
None
Graphical Representation
For inherited properties, show the property with restricted multiplicity in subtype, and using “{redefines <restricted-
property-name> }” at the end of the property entry in a class (can be elided), as shown in Figure 14.21.
<<owlClass> >
SingleColoredThing
hasColor : Color [ 1..1]
Alternatively, when unidirectional associations are desirable, cardinality constraints can be represented as shown in Figure
14.22.
1..1
+has Color
{redefines hasColor}
<<owlClass>>
SingleColoredThing
When class notation for properties is desirable, cardinality constraints can be represented as shown in Figure 14.23.
Description
The value constraint owl:allValuesFrom is a built-in OWL property that links a restriction class to either a class
description or a data range. A restriction containing owl:allValuesFrom specifies a class or data range for which all
values of the property under consideration are either members of the described class, or are data values within the
specified data range.
Essentially, owl:allValuesFrom is used to redefine the type of a particular property. In effect, this constraint defines a
subproperty similar to UML property redefinition.
None. Uses UML Generalization and property redefinition, as shown under Graphical Representation, below.
Note that the domain and/or target (for owl:allValuesFrom) for the subproperty will not always be a direct descendent
of the superclass that the property is defined on, as it happens to be in the examples.
If the attribute form of representation is used, then “{redefines <parent-class>::<property-name>}” should be given at the
end (i.e., to the right) of the property entry. The parent class is optional if the property inherits from only one parent.
Parent
None
Properties
None
Constraints
[1] Property name is not changed in redefinition.
[2] The redefined child class (or data range) must be stereotyped «owlClass» (or «owlDataRange»).
Graphical Representation
Several representation approaches are provided here, in keeping with the representation used for properties in the profile
for RDF/S. First, we can show the property with restricted type in subtype, by adding “{redefines <restricted-property-
name>}” at the end of the property entry (can be elided), as in Figure 14.24.
<<owlClass>>
Thing
hasColor : Color
<<owlClass>>
BrightColoredThing
hasColor : BrightColor { redefines hasColor }
+hasColor
<<owlClass>> {redefines hasColor} <<owlClass>>
BrightColoredThing BrightColor
<<objectProperty>>
HasColor
<<rdfsSubPropertyOf>>
<<objectProperty>>
HasBrightColor
+has Color
<<owlClass>> {redefines hasColor} <<owlClass>>
BrightColoredThing BrightColor
In addition to the «rdfsSubPropertyOf» stereotype, in order to facilitate disambiguation, vendors may optionally apply the
«owlValue» stereotype (defined in section 14.2.5.6) to the association redefining the property (i.e., the association
representing the restriction), by setting the allValuesFrom property to the class filling the value restriction with a
multiplicity of 1.
In cases where UML classes are used to represent OWL properties, the option shown in Figure 14.27, may be used.
Again, vendors may optionally apply the «owlValue» stereotype (defined in section 14.2.5.6) to the association redefining
the property (i.e., the association representing the restriction).
Description
Similar to owl:allValuesFrom, owl:someValuesFrom is a built-in OWL property that links a restriction class to
either a class description or a data range. A restriction containing an owl:someValuesFrom constraint is used to describe
a class or data range for which at least one value of the property concerned is either a member of the class extension of
the class description or a data value within the specified data range. In other words, it defines a class of individuals x for
which there is at least one y (either an instance of the class description or value of the data range) such that the pair (x,y)
is an instance of P. This does not exclude that there are other instances (x,y') of P for which y' does not belong to the class
description or data range.
The value constraint owl:hasValue is a built-in OWL property that links a restriction class to a value V, which can be
either an individual or a data value. A restriction containing an owl:hasValue constraint describes a class of all
individuals for which the property concerned has at least one value semantically equal to V (it may have other values as
well).
Again, like owl:allValuesFrom, owl:someValuesFrom and owl:hasValue are used to redefine the type of a
particular property, similar to UML property redefinition.
A stereotype «owlValue» with base class of UML::Property is applied to properties that are redefined. The stereotype has
these properties.
Parent
None.
Properties
Graphical Representation
The graphical notation for owl:someValuesFrom is the same as the notation given in Section 14.2.5.5 for
owl:allValuesFrom, with the distinction being the choice of property selected (someValuesFrom in this case). For
owl:hasValue, one option using the class notation is shown in Figure 14.28, below. Again in this case, use of the
«owlValue» stereotype, and property hasValue whose value would be the instance specification that is a member of the
singleton class, Red, is optional.
Description
owl:intersectionOf links a class to a list of class descriptions, describing an anonymous class for which the class
extension contains precisely those individuals that are members of the class extension of all class descriptions in the list.
«intersectionOf» is analogous to logical conjunction.
Parent
None
Properties
None
Constraints
[1] Applies to generalizations with a common subtype.
[2] All instances that are instances of every super type along generalizations that are stereotyped by «intersectionOf»
are instances of the subtype.
[3] (Semantic) All instances of the subtype are instances of all of the super types.
Dashed line between generalization lines with stereotype label, as shown in Figure 14.29.
<<intersectionOf>> - - - - - - - - - - - - - - - - - - -
<<owlClass >>
Tall Person
The stereotype is based on UML::Generalization rather than UML::Class, so there can be other supertypes not required by
the intersection. Use of UML::GeneralizationSet was prohibited in this case, because it requires one supertype – its
semantics refers to the instances of the subtypes, not the supertypes.
Description
owl:unionOf links a class to a list of class descriptions, describing an anonymous class for which the class extension
contains those individuals that occur in at least one of the class extensions of the class descriptions in the list.
owl:unionOf is analogous to logical disjunction.
No stereotype needed. Use UML::GeneralizationSet with isCovering = true, as shown in Figure 14.30. For consistency
with the other class descriptions, vendors can also optionally define a «unionOf» stereotype of UML::Constraint, applied
to UML::Generalization (similar to intersection, above).
Parent
None
Properties
None
Constraints
[1] (Semantic) All instances of the supertype are instances of at least one of the subtypes.
Graphical Representation
{ complete } - - - - - - - - - - - - - - - - - -- - - - - - -
<<owlClass>> <<owlClass>>
Male Female
Description
owl:complementOf links a class to precisely one other class, and describes a class for which the extension contains
exactly those individuals that do not belong to the extension of the other class. owl:complementOf is analogous to
logical negation: the class extension consists of those individuals that are NOT members of the extension of the
complement class.
Parent
None
Properties
None
Constraints
[1] Applies to constraints between exactly two classes.
[2] (Semantic). All instances (of owl:Thing) are instances of exactly one of the two classes.
Graphical Representation
Dashed line between two classes with stereotype label. An arrowhead should be used opposite from the class that will have
owl:complementOf in XML syntax (since all RDF, RDF Schema, and OWL graphs are unidirectional, by definition).
Shorthand representation that eliminates the arrowhead may be used within an ontology, but XML production in this case
should result in two instances of owl:complementOf – one for each “side” of the bidirectional constraint.
Description
owl:disjointWith is a built-in OWL property with a class description as domain and range. Each owl:disjointWith
statement asserts that the class extensions of the two class descriptions involved have no individuals in common. A class
axiom may also contain (multiple) owl:disjointWith statements. Like axioms with rdfs:subClassOf, declaring two
classes to be disjoint is a partial definition: it imposes a necessary but not sufficient condition on the class.
«disjointWith» with base class of UML::Constraint, or use disjoint UML generalizations with no stereotype.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between classes.
[2] (Semantic). An individual can only be a member of one class participating in a particular disjoint set of classes.
Graphical Representation
Dashed line between two classes with stereotype label. An arrowhead should be used opposite from the class that will have
«disjointWith» in XML syntax (since all RDF, RDF Schema, and OWL graphs are unidirectional, by definition). Shorthand
representation that eliminates the arrowhead may be used within an ontology, but XML production in this case should result
in two instances of «disjointWith» – one for each “side” of the bidirectional constraint.
<<owlClass>> <<owlClass>>
<<disjointWith>>
Male Female
In cases where there are multiple participants in the same «disjointWith» class axiom, a constraint note with stereotype
label and dashed lines to more than one class should be used, as shown in Figure 14.33.
Alternatively, if the classes have a common supertype, use UML::GeneralizationSet with isDisjoint = true. Representation is
dashed line between generalization lines labeled with “{disjoint}.”
<<owlClass>>
CelestialBody
{ disjoint } ------------------------
Description
owl:equivalentClass is a built-in property that links a class description to another class description. The meaning of
such a class axiom is that the two class descriptions involved have the same class extension (i.e., both class extensions
contain exactly the same set of individuals). A class axiom may contain (multiple) owl:equivalentClass statements.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between classes.
Graphical Representation
Dashed line between two classes with stereotype label. An arrowhead should be used opposite from the class that will have
owl:equivalentClass in XML syntax. Shorthand notation that eliminates the arrowhead may be used within an ontology, but
XML production in this case should result in two instances of «equivalentClass» – one for each “side” of the bidirectional
constraint.
Alternatively two UML::Generalizations may be used, again within a given ontology, if such circular definitions are
supported by the tool (i.e., class a generalizes class b and vice versa).
In cases where there are multiple participants in the same «equivalentClass» class axiom, a constraint note with stereotype
label and dashed lines to more than one class should be used, similarly to the example used for «disjointWith».
14.2.6 Properties
OWL distinguishes between two main categories of properties:
A property axiom defines characteristics of a property. In its simplest form, a property axiom just defines the existence of
a property. Often, property axioms define additional characteristics of properties. OWL supports the following constructs
for property axioms:
Description
A datatype property is defined as an instance of the built-in OWL class owl:DatatypeProperty. The built-in class,
owl:DatatypeProperty, is a subclass of the built-in class rdf:Property.
Note: In OWL Full, object properties and datatype properties are not disjoint. Because data values can be treated as
individuals, datatype properties are effectively subclasses of object properties. In OWL Full owl:ObjectProperty is
equivalent to rdf:Property. In practice, this mainly has consequences for the use of
owl:InverseFunctionalProperty.
Parent
«owlProperty»
Properties
None
Constraints
[1] (Semantics) The values of a property stereotyped by «datatypeProperty» must be either strings that can be
represented as UML::LiteralString stereotyped by «rdfsLiteral», values corresponding to the enumerated literals
represented as a UML::Enumeration stereotyped by «dataRange», or instances of a UML::Class stereotyped by
«rdfsDatatype» (i.e., one of the XML Schema Datatypes or a built-in datatype).
14.2.6.2 owl:ObjectProperty
Description
An object property is defined as an instance of the built-in OWL class owl:ObjectProperty. The built-in class,
owl:ObjectProperty, is a subclass of the built-in class rdf:Property.
If a property is declared to be inverse-functional, then the object of a property statement uniquely determines the subject
(some individual). More formally, if we state that P is an owl:InverseFunctionalProperty, then this asserts that a
value y can only be the value of P for a single instance x, i.e., there cannot be two distinct instances x1 and x2 such that
both pairs (x1, y) and (x2, y) are instances of P. See section 4.3.2 of [OWL Reference] for additional detail, including an
explanation of the notion of global cardinality constraints and use of owl:InverseFunctionalProperty to represent
keys in the context of a relational database.
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.
When one defines a property P to be a transitive property, this means that if a pair (x, y) is an instance of P, and the pair
(y, z) is also instance of P, then we can infer the pair (x, z) is also an instance of P.
«owlProperty»
Properties
• isInverseFunctional: Boolean [0..1] – when true, indicates that the property in question is inverse functional.
• isSymmetric: Boolean [0..1] – when true, indicates that the property in question is symmetric.
• isTransitive: Boolean [0..1] – when true, indicates that the property in question is transitive.
Constraints
[1] The type of a property stereotyped by «objectProperty» must be a UML::Class stereotyped by «owlClass».
[2] In OWL Full, the isInverseFunctional, isSymmetric, and isTransitive properties apply only to properties stereotyped
by «owlProperty», «objectProperty», or «datatypeProperty».
[3] In OWL DL, the isInverseFunctional, isSymmetric, and isTransitive properties apply only to properties stereotyped
by «objectProperty».
[4] The type of a property with isSymmetric set to true must be the same as the class on which it is defined.
[5] In OWL DL, no local or global cardinality constraints can be declared on a property with isTransitive set to true, or
on any of its super properties, nor on its inverse or on any super properties of its inverse.
14.2.6.3 owl:Property
Description
The notion of an owl:Property, as defined in the metamodel and redefined here in the profile is an abstract class.
A functional property is a property that can have only one (unique) value y for each instance x, i.e., there cannot be two
distinct values y1 and y2 such that the pairs (x, y1) and (x, y2) are both instances of this property. Both object properties and
datatype properties can be declared as “functional,” thus, we introduce it at owl:Property.
Parent
«rdfProperty»
Properties
• isFunctional: Boolean [0..1] – when true, indicates that the property in question is functional.
Constraints
[1] The isFunctional property applies only to properties stereotyped by «owlProperty», «objectProperty», or
«datatypeProperty».
Description
owl:equivalentProperty can be used to state that two properties have the same property extension. Syntactically,
owl:equivalentProperty is a built-in OWL property with rdf:Property as its domain and range.
Note: Property equivalence is not the same as property equality. Equivalent properties have the same “values” (i.e., the
same property extension), but may have different intensional meaning (i.e., denote different concepts). Property equality
should be expressed with the owl:sameAs construct. As this requires that properties are treated as individuals, such
axioms are only allowed in OWL Full.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between properties with «rdfGlobal» applied, or properties on the class at which they
are introduced.
[2] (Semantic) Instances of equivalent properties (property extensions, or sets of tuples) are the same.
Graphical Representation
Dashed line between two association classes with stereotype label. An arrowhead should be used opposite from the
association class that will have «equivalentProperty» in XML syntax. Shorthand notation that eliminates the arrowhead may
be used within an ontology, but XML production should result in two instances of «equivalentProperty» – one for each
“side” of the bidirectional constraint.
In cases where there are multiple participants in the same «equivalentProperty» relation, a constraint note with stereotype
label and dashed lines to more than one association class representing the property should be used, similarly to the example
for «disjointWith».
Description
OWL properties have a direction, from domain to range. In practice, people often find it useful to define relations in both
directions: persons own cars, cars are owned by persons. owl:inverseOf can be used to define such an inverse relation
between properties.
Syntactically, owl:inverseOf is a built-in OWL property with owl:ObjectProperty as its domain and range. An
OWL axiom of the form P1 owl:inverseOf P2 asserts that for every pair (x, y) in the property extension of P1, there
is a pair (y, x) in the property extension of P2, and vice versa. Thus, owl:inverseOf is a symmetric property.
«inverseOf» with base class of UML::Association, or use bidirectional associations with no stereotype.
Parent
None
Properties
None
Constraints
[1] Applies only to associations with «rdfGlobal» applied, or to properties on the class at which they are introduced.
[2] Applies only to binary, unidirectional associations.
[3] (UML) A property cannot be an inverse of itself (use the isSymmetric property).
Graphical Representation
A. The first is to use a simple association with properties as ends, i.e., a line between classes with properties on the
ends closest to their ranges, for example, as shown in Figure 14.36.
B. Alternatively, one could use an «inverseOf» stereotype of UML::Constraint between association classes for
binary, unidirectional associations, as shown in Figure 14.37. An arrowhead should be used opposite from the
association class that will have owl:inverseOf in XML syntax. Shorthand notation that eliminates the
arrowhead may be used within an ontology, but XML production should result in two instances of
«inverseOf» – one for each “side” of the bidirectional constraint.
<<inverseOf>>
<<inverseOf>>
<<objectProperty>>
sis terOf
+brotherOf
<<owlClass>> <<owlClass>>
Male Female
+sisterOf
C. A third notational option would be to use a stereotype «inverse» of a UML::Property with a property:
OF of type UML::Property
Using a similar representation to the approach taken in 14.2.5.6 (“owl:someValuesFrom and owl:hasValue Con-
straints”), put before the property name: “«inverse» {of = <property-name>, <property-name>}”.
14.2.7 Individuals
Individuals are defined with individual axioms (also called “facts”). These include:
Many languages have a so-called “unique names” assumption: different names refer to different things in the world. On
the web, such an assumption is not possible. For example, the same person could be referred to in many different ways
(i.e., with different URI references). For this reason OWL does not make this assumption. Unless an explicit statement is
being made that two URI references refer to the same or to different individuals, OWL tools should in principle assume
either situation is possible.
OWL provides three constructs for stating facts about the identity of individuals:
• owl:sameAs is used to state that two URI references refer to the same individual.
• owl:differentFrom is used to state that two URI references refer to different individuals
• owl:AllDifferent provides an idiom for stating that a list of individuals are all different.
Description
Many facts typically are statements indicating class membership of individuals and property values of individuals.
Individual axioms need not necessarily be about named individuals: they can also refer to anonymous individuals.
«owlIndividual» with a base class of UML::InstanceSpecification, typed by a class having the properties desired for the
individual. The class may be stereotyped by «singleton» to indicate it is for a specific individual5. Classes stereotyped by
«singleton» are not translated to OWL, and their properties appear in OWL as properties of the individual.
Parent
None
Properties
None
Constraints
[1] Classes stereotyped by «singleton» have exactly one instance each.
[2] The instance specification stereotyped by «owlIndividual» has only one value, i.e., it specifies a single individual.
Graphical Representation
Instance specifications use the same symbol as classes, but their names are underlined, and have a colon separating the
instance name from the class name. Singleton classes can be anonymous, omitted from the representation, and generated
by tools. Instances of anonymous classes show nothing after the colon.
Description
owl:sameAs links an individual to an individual, indicating that two URI references actually refer to the same thing: the
individuals have the same “identity.” owl:sameAs statements are often used in defining mappings between ontologies.
Additionally, in OWL Full, where a class can be treated as instances of (meta)classes, owl:sameAs can be used to define
class equality, thus indicating that two concepts have the same intensional meaning.
Parent
None
Properties
None
5. UML supports individuals without classes and properties on such individuals, for tools that choose to support it.
Graphical Representation
Dashed line between two instances (or classes) with stereotype label. An arrowhead can be used opposite from the
instance (or class) that will have «sameAs» in XML syntax.
Constraint note with stereotype label and dashed lines to more than one instance (or class - translates to multiple
«sameAs» statements).
<<sameAs>>
Description
The built-in owl:differentFrom property links an individual to an individual, indicating that two URI references refer
to different individuals.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between instance specifications.
Dashed line between two instances with stereotype label. An arrowhead can be used opposite from the instance that will
have «differentFrom» in XML syntax.
Constraint note with stereotype label and dashed lines to more than one instance (translates to multiple «differentFrom»
statements).
<<differentFrom>>
Description
For ontologies in which the unique-names assumption holds, the use of owl:differentFrom is likely to lead to a large
number of statements, as all individuals have to be declared pairwise disjoint. For such situations OWL provides a special
idiom in the form of owl:AllDifferent. owl:AllDifferent is a special built-in OWL class, for which the property
owl:distinctMembers is defined, which links an instance of owl:AllDifferent to a list of individuals. The intended
meaning of such a statement is that all individuals in the list are all different from each other.
Parent
None
Properties
None
Constraints
[1] Applies only to constraints between instance specifications.
Constraint note with stereotype label and dashed lines to more than one instance.
<<allDifferent>>
Description
In RDF, RDF Schema and OWL properties of individuals are accessed essentially through the triples (or statements),
where the individual is the subject of the triple. In this profile, while we have optionally provided explicit access to the
elements of the triple in a way that identifies the subject for this purpose, we also provide a more intuitive representation
from a UML perspective.
Parent
None
Properties
None
Constraints
[1] Values must conform to constraints on the property, such as type and multiplicity.
Graphical Representation
Put values after equal sign at end of property entry in instance.
14.2.8 Datatypes
OWL allows three types of data range specifications:
The RDF Semantics document recommends use of a subset of the simple built-in XML Schema datatypes. The set of
XML Schema datatypes that are allowable for use in OWL DL are given in the model library provided in Annex A.
Note: It is not illegal, although not recommended, for applications to define their own datatypes by defining an instance
of rdfs:Datatype. Such datatypes are “unrecognized,” but are treated in a similar fashion as “unsupported datatypes.”
Description
In addition to the RDF datatypes, OWL provides one additional construct for defining a range of data values, namely an
enumerated datatype, where the enumerated values are the enumeration literals (a kind of instance specification) of the
enumeration.
In OWL, this datatype format makes use of the owl:oneOf construct that is also used for describing an enumerated class.
In the case of an enumerated datatype, the subject of owl:oneOf is a blank node of class owl:DataRange and the object
is a list of literals.
Parent
None
Properties
None
Constraints
None
Graphical Representation
This chapter defines a UML2 profile to support the usage of UML notation for the modeling of Topic Maps.
Note that the structure of Topic Maps differs considerably from UML, making the profiles somewhat misleading. UML
specifies a class structure, with instances specified by a generic instances model. Topic Map constructs are largely at the
individual level, in some cases gathered into classes via a type association.
In particular, the stereotype Topic extends UML Class. An instance of Class is itself a class, while an instance of Topic in
the TM metamodel is generally not, although some instances of Topic serve as types for others. The profile only models
instances of Topic that are types.
Further, the stereotype Association extends UML Association. An instance of UML Association specifies a set of tuples.
An instance of TM Association specifies a particular link among particular individual instances of Topic. However, a TM
Association is linked to an instance of Topic that serves as its type. So the stereotype models the instance of Topic that is
the type of the TM Association.
15.1 Stereotypes
15.1.1 Topic Map
The Topic Map stereotype is defined as an extension of the UML Package base meta-class, as shown in Figure 15.1.
Applying this stereotype to a package requires that the UML constructs contained within the package be interpreted
according to this profile definition.
Tagged Values
• itemIdentifiers - used to specify the storage location of the Topic Map, it must be a URI String.
15.1.2 Topic
The Topic stereotype extends the UML Class meta-class, as shown in Figure 15.2. Its application indicates that the UML
Class is interpreted as a Topic that has been declared as a type, which takes other instances of Topic as instances.
Tagged Values
15.1.3 Association
The association stereotype extends the UML Association meta-class, as shown in Figure 15.3. Its application indicates the
UML Association is interpreted as a Topic Map Association. Both binary and n-ary associations are supported.
Note that the Topic Maps Association construct is an individual-level concept. The stereotype represents the topic that is
the type of a set of instances of Association. An association in UML includes a set of ends that are instances of Property
with associated Types. So, each instance of the Topic Map Association must be associated with the same pattern of
instances of AssociationRole that have the same corresponding instances of Topic as type, corresponding to the UML
association end properties. Further, each instance of Topic linked to an AssociationRole must be in a type-instance
relationship with an instance of Topic corresponding to the UML type of the corresponding UML property.
Tagged Values
• itemIdentifiers - used to specify the storage location of the Association, it must be a URI String.
15.1.4 Characteristics
The abstract class Characteristic is not a concept from [TMDM] nor is it used in the ODM Topic Maps metamodel. It is
used here to define a shared set of stereotypes that extend the UML Properties meta-class, as shown in Figure 15.4. All
the metaclasses extending Characteristics are individual-level concepts, so that the stereotypes all represent topics that are
either the type or scope of collections of instances.
Tagged Values
• name - used to specify the name of the Characteristic. Must be a String that can be a URI.
• datatype - used to specify the datatype of the Characteristic. Must be a String.
• value - used to specify the value of the Characteristic. Must be a String.
AssociationRole
The AssociationRole stereotype is used to indicate a UML Association owned end Property is a Topic Map
AssociationRole. The owning UML Association must be stereotyped using the Association stereotype. The stereotype
represents the instance of Topic that is the type of a collection of instances of AssociationRole.
Occurrence
The Occurrence stereotype may be applied to either a UML Attribute or a UML Association owned-end Property. Values
of this property are interpreted as Topic Map Occurrence values. The property itself represents the topic that is the type
of the collection of instances of Occurrence.
TopicName
The TopicName stereotype may be applied to char array or string typed attributes to indicate that values of the attribute
represent Topic Names. The property itself represents the topic that is the type of the collection of instances of
TopicName. The TopicName stereotyped Property may have multiple values for the tagged value ‘variant’ indicating a set
of Variant stereotype Properties that are associated with this TopicName.
Variant
The Variant stereotype may be applied to any UML Property, including attributes and association ends, to indicate these
values represent Variants. The property itself represents the topic that is the scope of the collection of instances of Variant.
The Variant stereotype Property is required to have a tagged value ‘parent’ linking the variant to a parent TopicName.
TopicMapCons truct
item Identifiers : s tring
<<s tereotype>> << ste re otyp e> > <<s tereotype>> << ste re otyp e> >
TopicMap Topic As so ciati on C ha ra cte ristic
Tagged Values
• itemIdentifiers - used to optionally provide an application specific unique identifier to the stereotyped elements; it
must be a URI String.
ScopedElement
scope : Topic
Tagged Values
• scope – a set of references to Topic Stereotyped elements that define the scope of the element.
15.2.3 TypedElement
Some stereotyped elements in the profiled model, as shown in Figure 15.7, may have a ‘type’ tagged value. This value
references a Topic stereotyped class that defines the general nature of the owning element.
< < ste re o typ e > > < <ste re o typ e > > < < ste re o typ e > > < < ste re o typ e > >
A sso ci a ti o n A sso ci a ti o n R o l e O ccu rre n ce T o p i cN a m e
Tagged Values
• type – a reference to a Topic stereotyped element that is the type of this element.
15.3 Example
Figure 15.8, show an example profile applied to a simple UML model of:
• Carl is a person that owns one Personal Car that is red and another that is blue.
+ isColor hasColor
+ owned ownership
C arl : Person
16.1 Introduction
This chapter provides an informative comparison between UML and the mandated ontology representation language
OWL. It compares the features of OWL Full (as summarized in OWL Web Ontology Language Overview [OWL OV])
with the features of UML 2.0 [UML2]. It first looks at the features the two have in common, although sometimes
represented differently, then reviews the features that are prevalent in one but not the other. Little attempt is made to
distinguish the features of OWL Lite or OWL DL from those of OWL Full. This overview also ignores secondary features
such as headers, comments, and version control. In the features in common, a sketch is given of the translation from a
model expressed in UML to an OWL expression. In several cases, there are alternative ways to translate UML constructs
to OWL constructs. This chapter selects a particular way in each case, but the translation is not intended to be normative.
In particular applications, other choices may be preferable.
This chapter also includes informative formal mappings from UML to OWL and from OWL to UML, both expressed in
QVT [MOF QVT].
UML models are defined within a larger meta-modeling framework standardized by OMG. This framework defines a
series of metalevels for UML:
• M3 is the MOF, the universal modeling language in which modeling systems are specified.
• M2 is the model of a particular modeling system. The UML metamodel is an M2 construct, as it is specified in the M3
MOF.
• M1 is the model of a particular application represented in a particular modeling system. The UML Class diagram
model of an order entry system is an M1 construct expressed in the M2 metamodel for the UML Class diagram.
• M0 is the population of a particular application. The population of a particular order entry system at a particular time is
an M0 construct.
Type +type
0..1
Generalization +ownedAttribute
+general n
Classifier Property
+specific 2..n
+memberEnd n
+ownedEnd
0..1
Class Association
0..1
0..1
The formal structure of UML is quite different from OWL. What we are trying to do is to understand the relationship
between an M1/M0 model in UML and the equivalent model in OWL, so we need to understand how the M1 model is
represented in the M2 structure shown. First, a few observations from Figure 16.1.
• Most of the content of a UML model instance is in the M1 specification. The M0 model can be anything that meets the
specification of the M1 model.
• There is no direct linkage between Association and Class. The linkage is mediated by Property.
• A Property is a structural feature (not shown), which is typed. The M1 model is built from structural features.
C o u rs e
S tu d e n t
c ode e n ro lle d
ID
d e s c rip t io n
nam e
N u m E n ro lle d
Property Type
code CourseIdentifier
description string
NumEnrolled integer
ID StudentIdentifier
name string
The association can be modeled in a number of different ways, depending on how classes are implemented. If classes are
implemented as in Table 16.2, one way is as the disjoint union of the owned attributes of the two classes.
Association Implementation
But there are other ways to implement a class. If it is known that the property code identifies instances of Course and that
the property ID identifies instances of Student, then an alternative implementation of enrolled is shown below:
Association Implementation
enrolled code, ID
In this case, the properties code and ID would be of type Course and Student respectively.
Both OWL and UML are based on classes. A class in OWL is a set of zero or more instances. A class in UML is a more
general construct, but one of its uses is as a set of instances. The set of instances associated at a particular time with a
class is called the class’ extent. There are subtle differences between OWL classes and UML classes that represent sets.
In UML the extent of a class is a set of zero or more instances of M0 objects. (Instances may be specified at the M1 level
in a model library, but they specify possibly several M0 objects.) An instance consists of a set of slots each of which
contains a value drawn from the type of the property of the slot. The instance is associated with one or more classifiers.
An instance of the class Course might be as shown in Table 16.5.
In OWL, the extent of a class is a set of individuals identified by URIs. Individual is defined independently of classes.
There is a universal class Thing whose extent is all individuals in a given OWL model, and all classes are subclasses of
Thing. The main difference between UML and OWL in respect of instances is that in OWL an individual may be an
instance of Thing and not necessarily any other class, so could be outside the system in a UML model. It is of course
possible to include a universal class in an M1 model library, but the concept is central to OWL.
An OWL class is declared by assigning a name to the relevant type. For example:
<owl:Class rdf:ID=”Course”/>
An individual is at bottom an RDFS resource, which is essentially a name, so the individual INFS3101 will be declared
with something like
<owl:Thing rdf:ID=“INFS3101”/>
Relationships among classes in OWL are called properties. That the class course has the relationship with the class
student called enrolled, which was represented in the UML model as the association enrolled, is represented in OWL as a
property.
<owl:ObjectProperty rdf:ID = “enrolled”/>
Properties are not necessarily tied to classes. By default, a property is a binary relation between Thing and Thing.
So, in order to translate the M1 model of Figure 16.2 to OWL, UML Class goes to owl:Class.
The relationships among classes represented in OWL by owl:ObjectProperty and owl:DatatypeProperty come from two
different sources in the UML model. One source is the M2 association ownedAttribute between Class and Property, which
generates the representation of a class as a bundle of owned attributes as in Table 16.2. An M1 instance of Class
ownedAttribute Property would translate as properties whose domain is Class and whose range is the type of Property.
An alternative way to give domain and range to OWL properties is to use restriction to allValuesFrom the range class
when the property is applied to the domain class. This is probably a more natural OWL specification. However, since all
OWL properties arising from a UML model are distinct, the method employed in this chapter is adequate. Should a
translation of a UML model be intended as a base for further development in OWL, an appropriate translation can be
employed (see Section 16.3).
Note that the translation in Table 16.7 assumes that a single name is an identifier for instances of the corresponding class.
This is not always true. That is there are cases in which a relational database implementation would use a compound key
to identify an instance of a class. Since OWL individuals are always unitary names, the translation of the UML class
would construct a unitary name from the values of the individual properties. For example, if the association enrolled were
treated as a class (UML association class), its representing property might be a concatenation of Course.code and
Student.id, so that the link for student 1234 enrolled in course INFS3101 might be translated to an OWL individual with
name a globalized equivalent of 1234.INFS3101. Alternatively, a system-defined name could be assigned, linked to each
name in the compound key by system-defined properties.
Both languages support the subclass relationship (OWL rdfs:subClassOf, UML generalization). Both also support
subproperties (UML generalization of association or meta-associations among properties like subsetting or redefining).
UML defines generalization at the supertype classifier, while in OWL subtype and subproperty are separately but
identically defined.
The translation from UML to OWL is straightforward. If <S, G> is an M1 instance of the UML M2 metaclass
generalization (S is a subclassifier of G), then if both S and G are classes and TS, TG are respectively the types of the
identifying owned property of S, G respectively, the OWL equivalent is the addition of the clause <rdfs:subClassOf
rdf:resource="TG"/> to the definition of the OWL class TS. Similarly if S and G are both associations, the owl equivalent
is the addition of the clause <rdfs:subPropertyOf rdf:resource="G"/> to the definition of the OWL object property S. Note
that subassociations can be defined in a number of ways, including by OCL.
enrolled
grade
instructor
Staff
ID
name
An association in UML can be N-ary. It can have its own ends (ownedEnd). An association can also be a class
(association class), so can participate in further associations. In OWL DL, classes and properties are disjoint, but in OWL
Full they are potentially overlapping. However, there is limited syntactic mechanism in the documents so far published to
This specification takes advantage of the fact that both an N-ary relation among types T1 ... TN and an association class
with attributes are formally equivalent to a set R of identifiers together with N projection functions P1, ..., PN, where Pi:R
-> Ti. Thereby both association classes and N-ary UML associations are translated to OWL classes with bundles of binary
functional properties.
Figure 16.3 extends the model of Figure 16.2 by making enrolled an association class that owns an attribute grade. The
association class enrolled is a member end of an association instructor, whose other member end is staff. Some students
enrolled in a given course may be assigned to one staff member as instructor, some as another.
end 2 Student
attri-bute Grade
Reification enrolledR
end 2 Staff
The association class enrolled is represented by its two end classes, Course and Student, the attribute of the association
class Grade, and by an owned attribute enrolledR that implements the association class as a class, in the same way as in
Table 16.3 and Table 16.4.
The implementation of enrolled and Instructor in Table 16.9 is translated into OWL as follows:
<owl:Class rdf:ID="enrolled" / >
<owl:FunctionalProperty rdf:ID="enrolledCourse">
<rdfs:domain rdf:resource="enrolled/>
<rdfs: range rdf:resource="Course"/>
</owl:FunctionalProperty >
<owl:FunctionalProperty rdf:ID="enrolledStudent">
<rdfs:domain rdf:resource=enrolled/>
<rdfs: range rdf:resource="Student"/>
</owl:FunctionalProperty >
<owl:FunctionalProperty rdf:ID="enrolledGrade">
<rdfs:domain rdf:resource=enrolled/>
<rdfs: range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:FunctionalProperty >
<owl:FunctionalProperty rdf:ID="enrolledenrolledR">
<rdfs:domain rdf:resource=enrolled/>
<rdfs: range rdf:resource=enrolledR/>
</owl:FunctionalProperty >
<owl:FunctionalProperty rdf:ID="instructor">
<rdfs:domain rdf:resource=enrolledR/>
There are a number of more advanced concepts in both UML and OWL. In the cases where the UML concept occurs in
OWL, the translation is often quite straightforward, so will not always be shown in this section (see Section 16.3 and
Section 16.4 for full details).
Both languages support a module structure, called package in UML and ontology in OWL. The translation of package to
ontology is straightforward. Both languages also support namespaces.
Both UML and OWL support a fixed defined extent for a class (OWL oneOf, UML enumeration). Note that in UML
enumeration is a datatype rather than a class.
UML has the option for associations to have distinguished ends that can be navigable or non-navigable. A navigable
property is one that is owned by a class or optionally an association, while a non-navigable is not (the end might be of
type integer, say). OWL properties always are binary and have distinguished ends called domain and range. A UML
binary association with one navigable end and one non-navigable end will be translated into a property whose domain is
the navigable end. A UML binary association with two navigable ends will be translated into a pair of OWL properties,
where one is inverseOf the other.
A key difference is that in OWL a property is defined by default as having range and domain both Thing. A given
property therefore can in principle apply to any class. So a property name has global scope and is the same property
wherever it appears. In UML the scope of a property is limited to the subclasses of the class on which it is defined. A
UML association name can be duplicated in a given diagram, with each occurrence having a different semantics. It is
possible, though not customary, to include a universal superclass in an M1 model library. This is sufficiently unusual that
it is not clear what the current toolsets would do with it.
An OWL individual can therefore be difficult to represent in a UML model. UML has a facility dynamic classification
that allows an instance of one class to be changed into an instance of another, which captures some of the features of
Individual, but an object must always be an instance of some class. UML models rarely include universal classes.
Both languages allow a class to be a subclass of more than one class (multiple inheritance). Both allow subclasses of a
class to be declared disjoint. (In OWL, all classes are subclasses of Thing, so any pair of classes can be declared disjoint.)
UML allows a collection of subclasses to be declared to cover a superclass, that is to say every instance of the superclass
is an instance of at least one of the subclasses. The corresponding OWL construct is the declare the superclass to be the
union of the subclasses, using the construct unionOf.
UML has a strict separation of metalevels, so that the population of M1 classes is distinct from the population of M0
instances and also the M1 model libraries. OWL Full permits classes to be instances of other classes. UML only models
classes of classes in the context of declaration of disjoint or covering powertypes.
In OWL, a property restriction applied to a class can impose a cardinality constraint giving the minimum
(minCardinality), maximum (maxCardinality), or exact number of instances that can participate in a relation (of the
specified type) with an instance of that class. In addition, an OWL property can be globally declared as functional
(functionalProperty) or inverse functional (inverseFunctional). A functional property has a maximum cardinality of 1
on its range, while an inverse functional property has a maximum cardinality of 1 on its domain. In UML an association
can have minimum and maximum cardinalities (multiplicity) specified for any of its ends. OWL allows individual-valued
properties (objectProperty) to be declared in pairs, one the inverse of the other.
For an N-ary UML association, multiplicities are more problematic to map to OWL. For example, in Figure 16.4 the
multiplicities show that:
• given instances of event, Olympiad, and competitor there is at most one instance of result.
• given instances of event, Olympiad, and result there is at most one instance of competitor.
• given instances of Olympiad, competitor, and result there may be many instances of event (an athlete may compete at
several events in the same Olympiad and finish in the same place in each).
• given instances of event, competitor, and result there may be many instances of Olympiad (an athlete may compete in
the same event at several Olympiads and finish in the same place in each).
For an N-ary UML association, any multiplicity associated with one of its end classes will apply to the OWL property
translating the corresponding projection from the association class to the translated end class.
co m p ete s 0 ..*
O lym p ia d
0 ..* ye a r
E vent
ev e n tID
0 ..1 0 ..1
R e su lt
C o m p e tito r p o sitio n
n am e
The N-ary association in Figure 16.4 would be translated as a class competes whose instances are instances of links in the
association, and four properties whose domain is competes and whose ranges are the classes attached to the member ends
of the association. Since one instance of a link includes only one instance of the class at each member end, all the
properties are functional. The multiplicities on the UML diagram do not translate to OWL in a straightforward way.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rdf:RDF [
<!ENTITY owl "http://www.w3.org/2002/07/owl#">
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
]>
<rdf:RDF xmlns:rdf="&rdf;"
xmlns:rdfs="&rdfs;"
xmlns:owl="&owl;"
xmlns:xsd="&xsd;"/>
<owl:Class rdf:ID="competes">
<owl:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="competesEvent"/>
<owl:minCardinality
In UML, multiplicities can be defined on both ends of an association. In OWL, general multiplicities apply to the range
instances associated with a given domain instance. In both cases, multiplicities can be strengthened (minimim increased
or maximum decreased) when associations/properties are applied to subclasses.
However, even if the property is mandatory (mincardinality > 0 and maxcardinality >= mincardinality), there may not be
definite values for the property. Consider a class (K) for which a property (P) is mandatory. In this case, the individual (I)
must satisfy the predicate
UML and OWL do not require that there is a constant C such that X = C, e.g., all horses have color, but we may not know
what color a particular horse has. As consequence of this possible indeterminacy, it may not be possible to compute a
transitive closure for a property across several ontologies, even if they share individuals.
In UML, there is a strict separation between the M1 and M0 levels. If an association is mandatory (minimum cardinality
greater than 0), it exactly matches the predicate [M]. Any difference between UML and OWL must come from the
treatment of the model of the M1 theory at the M0 level. In practice, implementations derived from UML models tend to
be ground Herbrand models implemented by something like an SQL database manager. For these cases, if we know a
horse has a color, then we know what color it has. To the extent that UML tools and modeling build this expectation into
products, conflict can occur when interoperating with an OWL ontology.
But UML does not mandate Herbrand compliance. It is possible for a particular application to introduce a special constant
“unknown” into a class, and define special treatment by the programs. UML does not forbid an implementation of a class
model in one of these ways. There is no difference in principle between UML and OWL for properties that are declared
to have minCardinality greater than 0 (and maxCardinality >= minCardinality) for a class.
An OWL property can have its range restricted when applied to a particular class such that the range is limited (subtype
of the property's range if declared) (allValuesFrom). UML permits these and other restrictions using the facilities: subsets,
specializes, or redefines. Often the specific restriction is defined in OCL.
OWL permits declaration of a property whose value is the same for all instances of a class, so the property value is in
effect attached to the class (OWL DL property declared as allValuesFrom a singleton set for that class). OWL full allows
properties to be directly assigned to classes without special machinery. In OWL, if class A is an instance of class B, then
a property P whose domain includes B will designate a value P(A) that can apply to the class A so it can be derived for
all instances of A.
UML allows a property to be derived from other model constructs, for example a composition of associations or from a
generalization. That a property is derived can be represented as an annotation in OWL. The actual derivation rule cannot
in general be represented in OWL (OWL does not support arithmetic, for example). Derivation rules in UML are
expressed in OCL, and there is no general translation of OCL to OWL.
A classifier in UML can be declared abstract. An abstract classifier typically cannot be instantiated, but may be a
superclass of concrete classifiers. There is no OWL equivalent for this.
Two different objects modeled in UML may have dependencies that are not represented by UML named (model)
elements, so that a change in one (the supplier) requiring a change in the other (the client) will not be signaled by, for
example, association links. Two such objects may be declared dependent. There are a number of subclasses of
This section has described features of UML and OWL that are in most respects similar. Table 16.10 summarizes the
features of UML in this feature space, giving the equivalent OWL features. UML features are grouped in clusters that
translate to a single OWL feature or a cluster of related OWL features. The column Package shows the section of the
UML Superstructure document [UML2] where the relevant features are documented.
navigable, non-navigable
derived
abstract classifier
Classes as instances
allValuesFrom, someValuesFrom
SymmetricProperty, TransitiveProperty
Classes as instances
disjointWith, complementOf
Mappings are expressed in QVT [MOF QVT]. A brief tutorial is presented in Annex H.
Mappings are shown for all constructs in Table 16.10 for which there is an OWL equivalent, except for Instance. The
Instance model is not part of the classes model, and is intended to show partial specifications of instances rather than
concrete instances. The profiles represent OWL individuals as singleton classes rather than UML instances. So the
mappings do not include Instance.
In OWL, all objects are identified either by uniform resource identifiers (uri) or by an arbitrarily assigned identifier
unique within the ontology (blank nodes). A typical method is for objects within an ontology to be identified by uri that
is a fragment on a base uri that identifies the ontology. It is also possible for an object to have a uri independent of that
of the ontology. Blank node identifiers can be treated as fragments in this way during the course of the mapping, even
though the identifiers do not persist. A uri is conceptually global. It universally identifies the same object no matter where
it appears.
Ontologies in OWL are free-standing objects that can import one another. Packages in UML can also import one another,
but in addition there is a standard procedure by which several packages may be merged into one.
A critical problem in mapping between UML and OWL is the generation of appropriate identifiers for objects in the target
model instance given the identifiers of the relevant objects found in the relevant pattern in the source model instance.
Since the mappings proceed from the packaging constructs to their components, the first problem is generation of an
identifier for the target packaging construct given the identifier of the source packaging construct. If the source is an
OWL ontology, one possibility is to identify the target package with the same uri as the ontology. However, this method
violates the spirit of the uri, since the same uri now identifies two different objects that could evolve independently. If the
source is a package, a base uri must be constructed for the target ontology. There is not enough information available in
the UML model instance to generate a globally unique uri.
Because of these incompatibilities, we have made use of two only partly specified relations, PackageNameToUriBase and
URIRefToName. PackageNameToUriBase takes a package name and creates a uri suitable to be extended by fragment
identifiers. URIRefToName takes a uri reference, possibly a fragment on a base uri, and generates a name unique to the
uri reference. (The relation takes distinct uri references to distinct names.)
Further, in mapping from UML to OWL, the target of objects whose names are unique within packages are identified by
uri references that are fragments on the uri base of the corresponding ontology. Targets of objects whose names are unique
only within a narrower context are identified by fragment identifiers generated by concatenating the name of the source
object with the names of its context objects starting with the object whose name is unique to a package. Thus an attribute
bar of a class foo would map to an object with fragment identifier foobar.
Each object in both the source and target model instance must have an identification scheme. Both UML and OWL
support the concept of a namespace represented as a packaging construct, called Package in UML and ontology in OWL.
Individual objects are contained in packaging constructs, and identified with respect to the identifier of their packaging
construct.
A package is a namespace for its members, and may contain other packages. Only packageable elements can be owned
members of a package. By virtue of being a namespace, a package can import either individual members of other
packages, or all the members of other packages.
// All objects in an OWL model instance are instances of OWLUniverse. Figure 16.10.
key OWLOntology(uriRef);
key OWLUniverse (uriRef, ontology);
key OWLUniverse (nodeID, ontology); // anonymous classes
relation PackageNameToUriBase
{
primitive domain pn: string;
enforce domain owl ref: URIReference{};
// Details of this relation are left to specific mappings
} // PackageNameToUriBase
The mapping from Class to OWLClass includes the transformation of generalization relationships between Classes.
A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each
instance of the specific classifier is also an indirect instance of the general classifier. It has the same semantics of
RDFSsubClassOf in RDF Schema, and the two ends of the generalization relationships can be accessed by the source and
target that are defined in DirectedRelationship.
The ownedAttribute defines the attributes owned by the class. It is an ordered set of Properties, which can be mapping to
either OWLDatatypeProperty or OWLObjectProperty. If a property is part of the memberEnds of an Association, the
mapping of it will be discussed in Association mapping sections [defined in Section 16.3.5 and Section 16.3.6].
If the type of the property is a PrimitiveType, the property is mapped to the OWLDatatypeProperty. If the type of the
property is an Enumeration, and the ownedLiteral of the Enumeration has specification as ValueSpecification, then the
property is OWLDatatypeProperty.
If the type of the property is Class, or the ownedLiteral of an Enumeration type has at least one classifier, the property can
be mapped to OWLObjectProperty.
top relation AttributeToObjectProperty
// maps ownedAttribute where property's type is a class to an object property
// notice that the enforce creates the more specific object OWLObjectProperty, then the more general structure Property is
created in the where clause. The when clause both forces the relation to wait until the classes have been mapped, and
gives the mappings for the classes.
{
checkonly domain uml prop : Property{class = cl : Class, type = tp : Class};
enforce domain owl op : OWLObjectProperty{RDFSdomain = dom : OWLClass, RDFSrange = ran : OWLClass};
when {
UClassToOClass(cl, dom);
UClassToOClass(tp, ran);
}
where {
PropertyToProperty(prop, op);
}
} // AttributeToObjectProperty
relation PropertyToProperty
// not a top relation. Intended to be called in a where clause of the relation mapping one of the more specific metaclasses.
It fills in the structures relevant to the superclass Property. Assumes the naming conventions for a property used as an
attribute.
{
cn, pn : string;
checkonly domain uml prop : Property{name = pn, class = :Class{
name = cn, owningPackage=p:Package}};
enforce domain owl op : Property{uriRef=:URIReference
{uri = ref : UniformResourceIdentifier, fragmentIdentifier=:LocalName{name=cnpn}}, ontology=o};
when{
PackageToOntology(p, o);
ref = o.uri; // Provides a base uri for the fragment identifier
}
where {
cnpn = cn + pn; // Follows naming conventions to disambiguate property name
}
} // PropertyToProperty
A binary association specifies a relationship that can occur between typed instances. It has exactly two ends represented
by properties, each of which is connected to the type of the end. The AssociationToObjectProperty relation is used to set
OWLinverseOf relationships between inverse properties.
Note that in this strategy the UML association name is not mapped, so even though the OWL to UML mapping
recognizes inverse pairs and maps them to associations, the association name is not recoverable.
relation EndPropertyToProperty
// not a top relation. Intended to be called in a where clause of the relation mapping one of the more specific metaclasses.
It fills in the structures relevant to the superclass Property. Assumes the naming conventions for a property used as an
association end.
{
an, pn : string;
checkonly domain uml prop : Property{name = pn, association = :Association{
name = an, owningPackage=p:Package}};
enforce domain owl op : Property{uriRef=:URIReference
{uri = ref : UniformResourceIdentifier, fragmentIdentifier=:LocalName{name=anpn}}, ontology=o};
when{
PackageToOntology(p, o);
ref = o.uri; // Provides a base uri for the fragment identifier
}
where {
anpn = an + pn; // Follows naming conventions to disambiguate property name
}
} // EndPropertyToProperty
An AssociationClass can be seen as an association that also has class properties, or as a class that also has association
properties. It not only connects a set of classifiers but also defines a set of features that belong to the relationship itself
and not to any of the classifiers.
Both association classes and N-ary associations are mapped to a class that is the domain of properties derived from each
of its ends.
16.3.7 Multiplicity
In UML, property is a MultiplicityElement, which defines upperValue and lowerValue to express cardinality. However,
OWL uses Restrictions to represent Cardinality. So in addition to map Class to OWLClass, some OWLRestrictions will
be generated based on multiplicity definitions of the ownedProperties and corresponding RDFSsubClassOf relationships
between OWLClass and OWLRestriction will also be created.
The relation mapping multiplicity can be a top relation, since having PropertyToProperty in the when clause delays its
execution until the RDFSdomain = structure in the enforce clause already exists. It is possible that there are several
domains for the property. This relation will force them all to be subclasses of the restriction class.
top relation UpperMultToMaxCard
// Upper multiplicity
{
m, n : string;
checkonly domain uml p : Property{upperValue = :ValueSpecification{value = m}};
relation BlankNodeID
// Make sure Blank node has a nodeID
{
n : string;
checkonly domain owl rest : OWLRestriction{};
enforce domain owl rest : OWLRestriction{nodeID = n};
where {
if rest.nodeID->isEmpty n = genAnonNodeID();
// Generates a unique blank node identifier
}
} // BlankNodeID
Several kinds of generalizations of properties and associations in UML are mapped to subproperty and subclass
relationships in OWL:
16.3.10 Powertypes
If a generalization set is covering, the general classifier is the union of the specific classifiers. If a generalization set is
disjoint, then the specific classifiers are pairwise disjoint. OWL does not support the equivalent for properties, so
generalization sets involving Associations are not mapped.
top relation IsCoveringToUnion
// Covering generalization set of classes goes to union
{
checkonly domain uml genset : GeneralizationSet{isCovering = true,
powertype = super : Class,
generalization = :Generalization{specific = speccl : Class}};
enforce domain owl ucl: UnionClass{OWLunionOf = osc : OWLClass};
when {
UClassToOClass(super, ucl);
UClassToOClass(speccl, osc);
}
}// IsCoveringToUnion
} // transformation UMLToOWL
In the profile, Individual is represented as a singleton class. This works well in a profile, because a profile is a tool of the
OWL ontology creator. The ontology creator would only model individuals in a profile if there were some special reason
to. They could, and probably would, choose not to represent the vast bulk of individuals in this way.
The mappings on the other hand have to treat all individuals uniformly. It would be possible to map individuals to
singleton classes, but then the mapping would have to deal with the RDFtype association. If an object is modeled as a
singleton class, then the subclass relationship is equivalent to the instance relationship, so it would be necessary to map
the RDFtype associations to subclass relationships in UML. This is probably not at all what one would generally want. In
terms of Gruber's ontology quality measures, this is enormous encoding bias.
Enumerated classes are represented in OWL as owl:oneOf class restrictions, where the enumeration is either a data range
(literals) or a set of individuals. Since individuals are not mapped, only the data range version of oneOf class restriction
is mapped.
UML has constructions corresponding to the OWL complementOf and disjointWith constructions in the PowerSets
package. These have been mapped in the UML to OWL mappings. However, in OWL these constructs are pairwise rather
than applying to an entire generalization set. Mapping pairwise restrictions like this is complicated, leading to a difficult-
to-read UML model. In these informative mappings, mappings for OWLcomplementOf and OWLdisjointWith are not
specified.
A problem is that multiple instances of domain or range specifications can come from a number of sources.
• Domain of the inverse of a property is range of the property, the range of the inverse is domain of a property
• Domain and range can be specified on superproperties of a property
• Combinations of these
The mappings assume that the OWL model instance mapped includes the deductive closure of all domain and range
specifications.
ontology owlUniver se
OWLOnt ology Universe
key OWLOntology(uriRef);
key OWLUniverse (uriRef, ontology);
key OWLUniverse (nodeID, ontology); // anonymous classes
// All objects in an OWL model instance are instances of OWLUniverse. Figure 16.10.
// Objects in UML have names relative to other constructs, ultimately to Package
key Package(name);
key Class(name, owningPackage);
key Association(name, owningPackage);
key UML::...::Kernel::Property(name, class);
key UML::...::Kernel::Property(name, association);
The Package construct in UML cannot be the source of properties. The only related structure is the facility to attach
comments inherited from NamedElement. Other than the mapping between importingOntology and packageImport,
ontology properties are therefore mapped to comments. Note that OWLversionInfo is not an Ontology property, but an
annotation property.
top relation PriorVersionInfoToComment
{
v : string;
checkonly domain owl ont : OWLOntology{OWLpriorVersion = :RDFSLiteral{lexicalForm = v}};
enforce domain uml pack : Package{ownedComment = :Comment{body = (“Prior Version “ + v)}};
when {
OntoToPackage(ont, pack);
}
} // PriorVersionInfoToComment
Classes in OWL are identified by uri, except for restriction classes that are blank nodes. A class in UML is identified by
name within package.
top relation OClassToUClass
{
checkonly domain owl cl:OWLClass {ontology = ont : OWLOntology};
enforce domain uml ucl:Class {owningPackage = pack : Package};
when {
OntoToPackage(ont, pack)
};
where {
UClassToClass(cl, ucl);
AnonClassToClass(cl, ucl);
}
} // OClassToUClass
An anonymous class in OWL is a blank node and is identified by a nodeID. This is unique within an ontology, if not
persistent. This identifier will serve as a name for the corresponding UML class, where the name is persistent.
relation AnonClassToClass
// map an anonymous OWL class to a UML class.
{
ID : string;
checkonly domain owl aclass:OWLClass {nodeID = ID};
enforce domain uml ucl : Class {name = ID};
when{
aclass.uriRef->isEmpty; // Some classes have also uri refs. These classes are not anonymous.
}
} // AnonClassToClass
16.4.5 Hierarchy
OWL has a universal superclass called owl:Thing acting as a default domain and range for properties. Need to create a
comparable UML class, called Thing (see Section 14.2.5).
top relation UniversalSuperclass
{
owlcl : OWLClass;
checkonly domain owl ont : OWLOntology{};
enforce domain uml thing : Class(name = “Thing”, owningPackage = pack : Package,
_class = ucl : Class}; // _class is opposite metaproperty to superClass
when {
OntoToPackage(ont, pack);
owlcl = ont.owlUniverse; // will instantiate for each OWL object which is an OWLClass
ucl = pack.ownedMember; // will instantiate for each ownedMember which is a Class
SubclassToGeneralization(owlcl, ucl); // forces wait until subclasses structure has been generated
ucl.superClass->isEmpty; // selects only those classes without superclasses
}
} //UniversalSuperclass
OWL allows classes to be constructed by union, intersection, and difference. OWL also allows classes to be declared
disjoint. Union and intersection can be mapped to subclass relationships, while disjoint and difference are not mapped.
top relation IntersectionToUML
// OWL intersection to subclass relationships
// Wil generate an instance of superClass for each instance of OWLintersectionOf
{
checkonly domain owl interclass : IntersectionClass{OWLintersectionOf = oclass : OWLClass,
ontology = ont : OWLOntology};
enforce domain uml usub:Class{superClass = uclass : Class, owningPackage = pack : Package};
when {
OntoToPackage(ont, pack);
OClassToUClass(interclass, usub);
OClassToUClass(oclass, uclass);
A data range in OWL is either a literal type or an enumeration of literals. The mapping of literal types is application
specific, but the enumeration corresponds to the enumeration in UML.
top relation EnumerationToEnumeration
{
checkonly domain owl edt:OWLDataRange{OWLoneOf = ol:RDFSLiteral{lexicalForm = v}};
enforce domain uml enum:Enumeration{ownedLiteral = ul : EnumerationLiteral};
where {
OWLLiteralToUMLLiteral(ol, ul); // Not supplied
OClassToUClass(edt, enum);
}
} // EnumerationToEnumeration
The restriction classes allValuesFrom, someValuesFrom, and HasValue all define subclasses of the domain on which a
specified property behaves in a specified way. UML does not have the machinery to represent the specified behavior. So
the mapping in each case is to an anonymous class, declared as a subclass of the domain of the property (if any), with the
restriction indicated in an attached comment. The mapping for hasValue only includes the case where the value is a literal,
since there is not a good general representation of Individuals in UML.
top relation AllValuesFromToClass
{
cn, pn : string;
up : UML:...:Kernel:Property;
checkonly domain owl avr : AllValuesFromRestriction{OWLallValuesFrom = oc : OWLClass,
OWLonProperty = op : RDFProperty};
enforce domain uml rcl : Class{comment = (“AllValuesFrom “ + cn + “ on “ pn)};
when {
OClassToUClass(avr, rcl);
OWLPropToUMLProp(op, up);
}
where {
cn = rcl.name;
pn = up.name;
relation SubclassOfPropDomain
// Makes UML mapping of restriction class subclas of mapping of property domain, if any
{
checkonly domain owl op:Property{RDFSdomain = oc : OWLClass};
enforce domain uml uc:Class{superClass = uc};
when {
OClassToUclass(oc, uc);
}
} // SubclassOfPropDomain
Properties in OWL are similar in concept to properties and associations in UML, but quite different in detail The
mappings follow as closely as possible the profiles given in Section 14.2.6.
• It is a datatype property.
• It is an object property with an inverse (including symmetric property). In this case the property and its inverse will be
mapped to the two ends of the association.
• It is inverse functional. An inverse functional property generates a partition of its range. Even if it has no inverse, it
must be mapped to an association because the corresponding multiplicity must apply to the end opposite the end
corresponding to the inverse functional property.
Cardinality constraints will be mapped to multiplicities, this includes functional and inverse functional properties.
A property can have possibly several classes declared as its domain, and possibly several declared as its range. In either
case the result is
• more than one class declared - the intersection of the declared classes.
relation PropertyToAProperty
// OWL property to UML property in context of an association end
{
identifier, un : string;
checkonly domain owl prop:Property{uriRef = :UniformResourceIdentifier{name = identifier}};
enforce domain uml uprop : Property{name = un};
where {
URIRefToName(identifier, un);
}
} // PropertyToAProperty
relation PropertyToOppProperty
// OWL property to opposite UML property in context of an association end (for inverse functional properties)
// This property has no corresponding OWL property, so can be fully specified.
{
identifier, un, onopp : string;
checkonly domain owl prop:Property{uriRef = :UniformResourceIdentifier{name = identifier}};
enforce domain uml uprop : Property{name = unopp, lowerValue = ‘0’, upperValue = ‘1’};
where {
URIRefToName(identifier, un);
unopp = “opposite_” + un;
}
} // PropertyToAProperty
relation OWLPropToUMLProp
// Returns the UML property corresponding to an OWL Property. The UML property has already been created.
{
checkonly domain owl prop:Property{};
enforce domain uml uprop : Property{};
when {
DTPropToAttribute(prop, uprop) OR
ObjPropToAttribute(prop, uprop) OR
PropertyToAProperty(prop, uprop);
}
} // OWLPropToUMLProp
16.4.10.1 Domains
top relation PropDomain
{
checkonly domain owl prop:Property {};
enforce domain uml cl : Class{};
where {
DefaultDomain(prop, cl);
SingleDomain(prop, cl);
MultDomain(prop, cl);
}
} // PropDomain
relation DefaultDomain
// Create default domain for property
{
checkonly domain owl prop:Property{ontology = ont : OWLOntology};
enforce domain uml usuper : Class{};
when {
prop.RDFSdomain->isEmpty; // no domains declared, so default
UniversalSuperclass(ont, usuper); // usuper has already been created for this ontology
}
} // DefaultDomain
relation SingleDomain
// Find single domain for property
{
checkonly domain owl prop:Property{RDFSdomain = dom: OWLClass, ontology = ont : OWLOntology};
enforce domain uml domcl : Class{};
when {
prop.RDFSdomain->size() = 1; // only one domain declared
relation MultDomain
// Find intersection of multiple domains for property as subclass called “DomainIntersection_” + name of property
// Assumed that the collection of domains of a property is the deductive closure of all sources of domains, in particular a
range of an inverseOf property
{
din : string;
obj : NamedElement;
checkonly domain owl prop:Property{RDFSdomain = dom: OWLClass, ontology = ont : OWLOntology};
enforce domain uml domintcl : Class{name = rin, superClass = domcl: Class,
owningPackage = pack :Package};
when {
prop.RDFSdomain->size() > 1; // if more than one domain declared
OClassToUClass(dom, domcl); // will be instantiated once for each class
OWLPropToUMLObj(prop, obj); // Need the property to be created so can get its name
OntoToPackage(ont, pack);
}
where {
din = “DomainIntersection_” + obj.name;
}
} // MultDomain
16.4.10.2 Ranges
top relation PropRange
{
checkonly domain owl prop:Property {};
enforce domain uml cl : Class{};
where {
DefaultRange(prop, cl);
SingleRange(prop, cl);
MultRange(prop, cl);
}
} // PropRange
relation DefaultRange
// Create default range for property
{
checkonly domain owl prop:Property{ontology = ont : OWLOntology};
enforce domain uml usuper : Class{};
when {
prop.RDFSrange->isEmpty; // no ranges declared, so default
UniversalSuperclass(ont, usuper); // usuper has already been created for this ontology
}
} // DefaultRange
relation SingleRange
// Find single range for property
{
checkonly domain owl prop:Property{RDFSrange = ran: OWLClass, ontology = ont : OWLOntology};
enforce domain uml rancl : Class{};
when {
prop.RDFSrange->size() = 1; // only one range declared
relation MultRange
// Find intersection of multiple ranges for property as subclass called “RangeIntersection_” + name of property
// Assumed that the collection of ranges of a property is the deductive closure of all sources of ranges, in particular a
domain of an inverseOf property
{
rin : string;
obj : NamedElement;
checkonly domain owl prop:Property{RDFSrange = ran: OWLClass, ontology = ont : OWLOntology};
enforce domain uml ranintcl : Class{name = rin, superClass = rancl: Class,
owningPackage = pack : Package};
when {
prop.RDFSrange->size() > 1; // if more than one range declared
OClassToUClass(ran, rancl); // will be instantiated once for each class
OWLPropToUMLObj(prop, obj); // Need the property to be created so can get its name
OntoToPackage(ont, pack);
}
where {
rin = “RangeIntersection_” + obj.name;
}
} // MultRange
relation CardToULMult
// max and min cardinality are the same
{
c : string;
checkonly domain owl oprop : Property{
relation MaxCardToUMult
// max cardinality
{
u : string;
checkonly domain owl oprop : Property{
propertyRestriction = :MaxCardinalityRestriction{OWLmaxCardinality = :TypedLiteral{lexicalForm = u}}};
enforce domain uml uprop : Property{upperValue = u};
} //MaxCardToUMult
relation MinCardToLMult
// min cardinality
{
l : string;
checkonly domain owl oprop : Property{
propertyRestriction = :MinCardinalityRestriction{OWLminCardinality = :TypedLiteral{lexicalForm = l}}};
enforce domain uml uprop : Property{lowerValue = l};
} //MinCardToLMult
relation FunctionalToUMult
// Functional property
{
checkonly domain owl oprop : FunctionalProperty{};
enforce domain uml uprop : Property{upperValue = “1”};
} //FunctionalToUMult
relation InvFunctionalToUMult
// If a inverse functional property has an inverse, the multiplicity goes on the inverse
{
checkonly domain owl ifprop : InverseFunctionalProperty{};
enforce domain uml opprop : Property{upperValue = ‘1’};
when {
ifprop.OWLinverseOf->exists(invprop : Property | PropertyToAProperty(invprop, opprop))
or
ifprop.inverseProperty->exists(invprop : Property | PropertyToAProperty(invprop, opprop))
}
} // InvFunctionalToUMult
relation AddUnlimitedMax
// Add unlimited max cardinalities to UML properties with no max cardinality
{
enforce domain uml prop:Property{upperValue = “*”};
when {
prop.upperValue->isEmpty;
}
} // AddUnlimitedMax
relation AddZeroMin
// Add zero min cardinalities to UML properties with no min cardinality
{
enforce domain uml prop:Property{lowerValue = “0”};
when {
OWL has an annotation property facility, including several built-in annotation properties, whose domain is
OWLUniverse, while UML has only comments on NamedElement. Note that OWLversionInfo is an annotation property,
not an ontology property. Note also that since the mapping doesn’t map Individuals to UML, annotation properties on
individuals are not mapped.
The built-in annotation properties are modeled as meta-associations, while the user-defined annotation properties are
instances of OWLAnnotationProperty.
top relation VersionInfoToComment
{
v : string;
checkonly domain owl res :OWLUniverse{OWLversionInfo = :RDFSLiteral{lexicalForm = v}};
enforce domain uml ne :NamedElement{ownedComment = :Comment{body = (“Version “ + v)}};
when {
UniverseToNamedElement(res, ne);
}
} // VersionInfoToComment
relation UniverseToNamedElement
{
checkonly domain owl res :OWLUniverse{};
enforce domain uml ne :NamedElement{};
when {
} // transformation OWLUMLSource
OWL permits a subclass to be declared using subClassOf or to be inferred from the definition of a class in terms of other
classes. It also permits a class to be defined as the set of individuals that satisfy a restriction expression. These
expressions can be a boolean combination of other classes (intersectionOf, unionOf, complementOf), or property value
restriction on properties (requirement that a given property have a certain value – hasValue). The property
equivalentClass applied to restriction expressions can be used to define classes based on property restrictions.
defines the class TexasThings as a subclass of the domain of the property locatedIn. These individuals are precisely those
for which the range of locatedIn is in the class TexasRegion. Given that we know an individual to be an instance of
TexasThings, we can infer that it has the property locatedIn, and all of the values of locatedIn associated with it are
Because it is possible to infer from the properties of an individual that it is a member of a given class, we can think of the
complex classes and property restrictions as a sort of predicate definition language.
UML provides but does not mandate the predicate definition language OCL. Note that a subsumption reasoner could be
built for UML. But because UML is strongly typed, it could work in the way mandated for OWL only if there were a
universal superclass provided in the model library, which is rarely provided in practice.
OCL and CL (Common Logic) are two predicate definition languages that are relevant to the ODM. Both are more
expressive than the complex class and property restriction expressions of OWL Full. There are also other predicate
definition languages of varying expressive powers that particular applications might wish to use.
The ODM does not mandate any particular predicate definition language, but will provide a place for a package enabling
the predicate definition language of choice for an application. In particular, the ODM includes a metamodel for CL.
16.5.2 Names
A common assumption in computing applications is that within a namespace the same name always refers to the same
object, and that different names always refer to different objects (the unique name assumption). As a consequence,
given a set of names, one can count the names and infer that the names refer to that number of objects.
Names in OWL do not by default satisfy the unique name assumption. The same name always refers to the same object,
but a given object may be referred to by several different names. Therefore counting a set of names does not warrant the
inference that the set refers to that number of objects. Names, however, are conceptually constants, not variables.
OWL provides features to discipline names. The unique name assumption can be declared to apply to a set of names
(allDifferent). One name can be declared to refer to the same object as another (sameAs). One name can be declared to
refer to something different from that referred to by any of a set of names (differentFrom).
Two classes can be stated to be equivalent (equivalentClass) and two properties can be stated to be equivalent
(equivalentProperty). Equivalent classes have the same extents, equivalent properties link the same pairs.
UML supports named elements with namespaces only at the M1 level. Although a UML class may be defined to contain
a definite collection of names, names at the M0 level are not prescribed. Applications modeled in UML are frequently
implemented using systems like SQL that default the unique name assumption, but this is not mandated. UML places no
constraints on names at the M0 level.
In particular, it is permitted for applications modeled in UML to be implemented at the M0 level using names that are
existentially quantified variables. Note that the UML constraint language OCL uses variables. OWL does not support
variables at all.
There are a number of developments related to OWL that are not yet finalized, including SWRL Semantic Web Rule
Language and OWL services. These are considered out of scope for the ODM. A translation of an out-of-scope model
element will be to a comment in the OWL target.
UML allows the specification of behavioral features, which declare capabilities and dynamic aspects of the system. OCL
can be used to restrict derived properties. Facilities of UML that can be used to describe application programs include:
• interface classes, which specify an interface to a set of attributes and operations that could be implemented by one or
more classes; and
• active classes, which are classes that have a separate thread of execution control for each instance.
UML supports various flavors of the part-of relationship between classes. In general, a class (of parts) can have a part-of
relationship with more than one class (of wholes). One flavor (composition) specifies that every instance of a given class
(of parts) can be a part of at most one whole. Another (aggregation) specifies that instances of parts can be shared among
instances of wholes.
Composite structures defined in classes specify runtime instances of classes collaborating according to connectors.
They are used to hierarchically decompose a class into its internal structure that allows a complex object to be broken
down into parts. These diagrams extend the capabilities of class diagrams, which do not specify how internal parts are
organized within a containing class and have no direct means of specifying how interfaces of internal parts interact with
its environment.
Ports model how internal instances are to be organized. Ports define an interaction point between a class and its
environment, or a class and its contents. They allow you to group the required and provided interfaces into logical
interactions that a component has with the outside world. Collaboration provides constructs for modeling roles played by
connectors.
Although not strictly part of the complex object feature set, the feature template (parameterized class) is most useful
where the parameterized class is complex. One could for example define a multimedia object class for movies, and use it
as a template for a collection of classes of genres of movie, or a complex object giving the results of the instrumentation
on a fusion reactor that would be a template for classes containing the results of experiments with different objectives.
Although it is recognized that there is a need for facilities to model mereotopological relationships in ontologies, and
UML provides a capability in this space, there does not seem to be sufficient agreement on the scope and semantics of
existing models for inclusion of specific mereotopological modeling features into the ODM at this stage.
UML permits a property to be designated read-only. It also allows classes to have public and private elements. ODM
omits access control features.
UML has keywords that are used to extend the functionality of the basic diagrams. They also reduce the amount of
symbols to remember by replacing them with standard arrows and boxes and attaching a <<keyword >> between
guillements. A common feature that uses this is <<interfaces>>. ODM omits this feature.
16.6.5 Profiles
UML has a facility called Profile, whereby a specialist developer can make lightweight extensions to the modeling
language by defining stereotypes, which define subclasses of metaclasses. This enables the developer to either articulate
the metaclass into a number of kinds or to rename the metaclass.
OWL DL does not have a facility like this. One can achieve the same effect in OWL Full by defining subclasses of
owl:Class or rdf:Property, since OWL is its own metalanguage.
Profiling in UML is necessary because of the strict separation of metalevels, and is useful partly because it allows re-use
of the UML graphical rendering conventions, and also the UML graphical editors and other tools. OWL does not at
present have a standard graphical representation. Because OWL DL does not support an equivalent of stereotypes, and
because the functional equivalent of stereotypes in OWL Full is a user capability rather than a metamodeler capability as
in UML, the mappings from UML to OWL and from OWL to UML disregard this feature.
17.1 Overview
The mappings in this and the other mapping chapters of the ODM are expressed in the Relations language of QVT [MOF
QVT]. A brief tutorial on this system is given in Annex H, MOF QVT: A Brief Tutorial.
The mappings in this chapter are semantic mappings in terms of the W3C Semantic Web Best Practices and Deployment
Group work-in-progress paper [RDF/TM], and where possible follow its suggestions. A Working Group Note or
Recommendation is planned, which may require that these mappings be revised during Finalization.
Note that the suggestions in [RDF/TM] are based on an earlier version of the Topic Maps Data Model than the ODM. The
more recent version has many changes. Further, the mappings referred to in [RDF/TM] are all to RDF, whereas the
mappings in the ODM are to OWL Full.
There is a significant structural mismatch between Topic Maps and OWL, which is at least partly mediated by the ODM
OWL metamodel. In Topic Maps, as in UML, all objects are contained in packaging structures, which in Topic Maps is
the metaclass TopicMap. In OWL, all objects are instances of the metaclass RDFSResource. In RDFS, a resource is
conceived of as an object “in the world” that an ontology may make statements about. An ontology is a collection (graph)
of statements, each of which refers to resources, but given a resource we can’t in principle navigate to the statements that
refer to it. This is analogous to the fact that a web page may be linked to by many other web pages, but there is no reverse
navigation. The site <omg.org> is the target of links from many sites, but there is no easy way for the OMG to know what
those sites are.
However, a resource referred to in an OWL ontology is always an instance of one of the ODM OWL metaclasses. The
declaration (in OWL) that a resource is an instance of one of the OWL metaclasses is a statement in a definite OWL
ontology. It is possible to navigate from that declaration to the ontology it is asserted in. This situation is modeled in the
OWL metamodel by the structures shown in Figure 11.8.
QVT needs to know how the various constructs are identified. The key statement can tell which model the class is in if
the class’ name is unique within the two models.
All objects in OWL (Full) are instances of Individual. But QVT does not support overlapping subtypes, so that the
identifier is supplied by the common supertype of all OWL objects, OWLUniverse (Figure 11.8). The identifier URI is
inherited from the superclass RDFSResource. URI is a unique identifier if the object has a URI. But in OWL the type of
a resource depends on the ontology.
A blank node does not have a URI. It is identified by a nodeID. The subclass BlankNode of OWLUniverse is defined by
the presence of a nodeID attribute. The attribute nodeID is unique within a given repository population. It is the
responsibility of the ontology server to main this uniqueness. But there is no requirement that the value of nodeID will be
the same for different queries to the repository. Note that in OWL blank nodes occur only as restriction classes and the
like, so are always used in declarations that are statements in a particular ontology.
key Statement(RDFSsubject, RDFSpredicate, RDFSobject, ontology);
Topic Maps has a most general constuct, the abstract class TopicMapConstruct.
Topic map constructs have a complex system of identifiers. A construct has a possibly empty set of itemIdentifiers, each
which is identifying. A topic has in addition a possibly empty set of subjectIdentifiers and a possibly empty set of
subjectLocators, each of which is identifying. There is a constraint that an instance of TopicMapConstruct has at least one
identifier, so that it is not valid for all of the properties to be empty.
Since different subclasses of TopicMapConstruct have different identification schemes, they are enumerated in the key
statements. But Topic has several alternate keys. The following key declarations have the semantics that the first applies
unless its property is empty. In that case, the second applies, and so on.
The basic packaging construct in Topic Maps is TopicMap, while the basic packaging construct in OWL is
OWLOntology. In each case, the package can contain other packages. In TM, a TopicMap can have a reifer that belongs
to another topic map, while in OWL, one OWLOntology can import another. Instance models of these are shown in
Figure 17.1.
• Topic maps are nested as a tree. Therefore there is a top topic map.
• The top topic map has an IRI among its identifiers. If not, one can be added.
Each topic map has an IRI among its itemIdentifiers. (If a topic map does not have an IRI among its identifiers, it can be
merged with its parent.)
reifier parent
tma :TopicMap tmb :TopicMap
itemIdentifiers :Topic itemIdentifiers
importingOntology
onta :OWLOntology ontb :OWLO ntology
uriRef uriRef
The packaging construct TopicMap goes to OWLOntology. Topic Maps included in other topic maps are mapped to
ontologies which are imported by other ontologies.
function TMiri(identifier : string) : boolean
// True if the identifier conforms to the syntax of a URI
{
// Details left to concrete implementations
} // TMiri
relation IDtoURIRef
// if ident is a uri then return ident else make uri reference from base and ident
checkonly domain tmap ident:string, base:string{};
enforce domain owlont uriref: URIReference {};
where {
if TMiri(ident) then URItoURIRef(ident, uriref)
else FragToURIRef(ident, base, uriref);
}
} // IDtoURIRef
relation URItoURIRef
// string is already uri
checkonly domain tmap ident:string{};
enforce domain owlont uriref: UniformResourceIdentifier{name = ident};
} // URItoUIRRef
relation FragToURIRef
// construct uri from base and fragment
checkonly domain tmap ident:string, base:string {};
enforce domain owlont uriref : URIReference{uri = :UniformResourceIdentifier{name = base},
fragmentIdentifier = :LocalName{name = ident}};
} // UFragToURIRef
• Topics that are the type of an association but not a structural type
:Topic
subjectIdentifiers = ‘tmcore:type’
inst:Topic
type
asr:AssociationRole :Association
roles parent
:Topic
subjectIdentifiers = ‘tmcore:type-instance’’ type
Figure 17.2 Type-instance structure in TM. Instances of Figure 13.2 and Figure 13.3
:Topic
subjectIdentifiers = ‘tmcore:subType’
type
roles
subt:Topic player asr_subt:AssociationRole assoc:Association
supert:Topic asr_supert:AssociationRole
player roles
type
:Topic
subjectIdentifiers = ‘tmcore:superType’
type
:Topic
subjectIdentifiers = ‘tmcore:superType-subType’
Figure 17.3 - Subtype-supertype structure in TM. Instance of Figure 13.2 and Figure 13.3
type
parent
inst:Topic asr_ii:AssociationRole assn:Association
roles
typetop:Topic asr_tt:AssociationRole
player roles
type
type
:Topic :Topic
subjectIdentifiers = ‘tmcore:type’ subjectIdentifiers = ‘tmcore:type-instance’
Figure 17.4 - Topic structure for typed Individual. Instances of Figure 13.2 and Figure 13.3
An n-ary association is linked to n instances of AssociationRole, each of which is mapped to a property. Like the mapping
of UML association classes, this strategy does not privilege binary associations. Binary associations in Topic Maps do not
provide sufficient information to specify the directionality of an OWL property. On the other hand, this approach works
for unary associations as well as any other.
Several association types are used for structural purposes, so are excluded from this mapping.
type type
roles
top :Topic role:AssociationRole assoc:Association
player
}
} // RoleToStatement
parent type
occ : Occurrence
top :Topic value = vname toptype :Topic
datatype : string
Figure 17.6 - Occurrence Instances. Instance of Figure 13.2 and Figure 13.3
}
} // OccurInstToStatement
Variant names are mapped to values of a property whose uri is the Topic Map published subject ‘tmcore:variant-name.’
Some variants are resources while some are literals. But all variants have a scope, so the object of a variant is mapped to
an Individual. The value of the variant whose datatype is not URI is mapped to a label of the object Individual. In this
case the individual will be a blank node. The repository is responsible for assigning differentiating nodeID attributes to
blank nodes.
topicNames
n : TopicName
:Topic
value = tn
type v :Variant
toptype:Topic value = vname
variants
datatype : string
scope
st:Topic
Figure 17.7 - Topic Name and Variant Name. Instances of Figure 13.2 and Figure 13.3
relation VariantToDTProp
// Variant which is not a uri to object property statement whose object has the value as a label. Figure 13.2 Object will be
a blank node. Repository is responsible for assigning differentiating values of nodeID to blank nodes.
{
vname : string;
sst : Statement;
ont : Ontology;
tm : TopicMap;
checkonly domain tmap n:TopicName {variants = v:Variant};
enforce domain owlont ost:Statement {
RDFSpredicate = op : OWLObjectProperty {uriRef = :UniformResourceIdentifier
{name = ‘tmcore:variant-name’}),
RDFSsubject = sub : Individual,
RDFSobject = obj : Individual {RDFSlabel = pl : PlainLiteral {lexicalForm = vname}},
ontology = ont};
when {
v.datatype->exists(dt | dt <> ‘uri’) and
v.value->exists(vname);
TMCToOntoObjs(n, sub); // Created Individual
}
where {
TMCToOntoObjs(v, obj); // Created Individual
tm = TMCToTM(n); // Find ontology corresponding to TopicName
TMapToOnto (tm, ont); // Assumes ontolory target already exists. OK because relation is a top relation
VariantScope(v, sst : Statement);
}
} // VariantToDTProp
relation VariantScope
// All variants have a scope. Mapped to a statement. Depends on Variant and Topic (scope).
{
tm : TopicMap;
ont : Ontology;
checkonly domain tmap v:Variant {scope = st : Topic};
enforce domain owlont ost:Statement {
RDFSpredicate = op : OWLObjectProperty {uriRef = :UniformResourceIdentifier{name = ‘tmcore:scope’}},
RDFSsubject = sub : Individual,
RDFSobject = obj : Individual,
ontology = ont};
when {
TMCToOntoObjs(v, sub); // Created Individual
TopicToIndividual(st, obj); // Created Individual
}
where {
tm = TMCToTM(v); // Find ontology corresponding to Variant
TMapToOnto (tm, ont); // Assumes ontolory target already exists. OK because relation is a top relation
}
} // VariantScope
} // transformation TMapOntoSource
tsub:Topic
type type
roles
subtop:Topic asrsub:AssociationRole assoc:Association
player
roles
objtop:Topic asrobj:AssociationRole
player
type
topj:Topic
subjectIdentifiers = ‘rdfobject’
Figure 17.9 - Topic Map target of object property statement Figure 13.2 and Figure 13.3
} // transformation OntoTMapSource
18.1 Overview
Mapping from the W3C Semantic Web languages, the Resource Description Framework [RDF Primer] [RDF Concepts]
and the Web Ontology Language [OWL S&AS] to Common Logic (CL) is relatively straightforward, as per the draft
mapping under development by Pat Hayes [SCL Translation] for incorporation in ISO 24707 [ISO 24707]. The mapping
supports translation of RDF vocabularies and OWL ontologies from the RDFS and OWL metamodels, respectively, to the
CL metamodel, in the spirit of the language mapping. Users are encouraged to familiarize themselves with the original
translation specification and to recognize that the overarching goal is to preserve not only the abstract syntax of the source
languages but their underlying semantics, such that CL reasoners can accurately represent and reason about content
represented in knowledge bases that reflect those models. The mapping, as it stands, is intended to take an RDFS/OWL
ontology as input and map it directly to CL from the triple format. Additional work, including (1) a direct mapping from
an RDFS/OWL ontology represented solely in a UML/MOF environment using the metamodels and profiles contained
herein, (2) representation of the mappings using MOF QVT, (3) a lossy, reverse mapping from CL to RDFS/OWL using
MOF QVT to preserve lossy information, and (4) bi-directional mappings from CL to and from UML 2, again using MOF
QVT to preserve lossy information, are planned.
Note that we have not attempted to address the issues raised in [SCL Translation] regarding the distinction between an
embedded or translation approach to determining how to map language constructs – such decisions are left to the vendor,
depending on the target application(s).
These two approaches are completely compatible, and the relationship between them can be expressed through the axiom:
(forall (x y z)(iff (rdf_triple y x z)(x y z)))
The translation extends this notion further through to ensure that the predicate expressed by the triple is indeed a valid
RDF property, the “cautious translation approach.”
For the purposes of this specification, any RDF or RDFS predicate that is not explicitly mapped to CL can be translated
directly using this method.
The RDF vocabularies for reification, containers, and values have no special semantic conditions, so translate uniformly
into CL using the above conversion methods.
Taken together, these axioms justify the more efficient mapping of RDFS triples to CL given in Table 18.3, to be used in
place of Table 18.1.
RDFS Metamodel Element RDFS Metamodel Property CL Metamodel Element CL Metamodel Property
The translations are ordered, with the second used only when the first does not apply.
The above example now translates into the more intuitive form
(exists (x y)
(and
(ex:firstName x (xsd:string 'Jack'))
(ex:Human x)
(Married x y)
(ex:firstName y (xsd:string 'Jill'))
))
Similarly to the case for RDF, this assumes that every unary predicate corresponds to an RDFS class; to be more cautious,
one would omit the promiscuity axiom and insert an extra assumption explicitly as part of the translation process: if (1),
add axiom (rdfs:Class bbb); otherwise, (2) add axiom: (rdf:Property ppp).
A series of tables encoding numerous axioms is provided in [SCL Translation] that reflect the axiomatic triples, RDFS
“semantic conditions,” and extensional axioms, as well as axioms for interpreting datatypes, which are incorporated
herein by reference. Some of these are summarized in an RDFS extensional logical form translation table, which may be
more efficient than deriving the translation from the embedding and axioms.
.
Table 18.4 - RDFS Extensional Logical Form Translation
Relation predicate:aaa
arguments [1]: u
Where possible clauses included in sentences, such as the antecedent and consequent of an implication, are expanded for
further clarification. The translations are ordered, with the final one used only when the others do not apply.
The discussion provided in [SCL Translation] provides additional insight into the variations among OWL dialects. It then
provides an unrestricted translation from the OWL vocabulary to CL, and further refines it for each dialect given a
common starting point. There are a number of important considerations provided in that discussion, including a series of
axioms applicable to any CL reasoning environment designed to support OWL ontologies as input.
Table 18.5 provides a summary translation from RDFS/OWL triples, as represented in the metamodel triple constructs,
mapped to the appropriate high-level CL metamodel sentence constructs. We’ve taken this approach in keeping with the
translation, but also due to the fact that what is mapped in some cases is actually a subgraph consisting of multiple RDFS/
OWL statements as well as for increased clarity. Further refinement of some of the CL sentences will be accomplished
during the finalization phase of the specification, along with inclusion of examples. The translation assumes the axioms
stated in Section 18.1 and Section 18.2, as well as the following identity axioms:
(forall ((x owl:Thing)(y owl:Thing))(iff (owl:differentFrom x y)(not (= x y)) ))
Note that OWL assertions involving annotation and ontology properties are not covered explicitly, and should be simply
transcribed as atomic assertions in CL, using the same mechanisms described for RDF triples.
To use the table below to translate an OWL/RDF graph, simply generate the corresponding CL for every subgraph that
matches the pattern specified in the leftmost two columns. The notation ALLDIFFERENT is used as a shorthand for
conjunction of n(n-1) “inequations” which assert that the terms are all distinct:
means:
(and
(not (= x1 x2)) (not (=x1 x3)) ... (not (= x1 xn))
(not (= x2 x3)) ... (not (= x2 xn))
(not (= x3 xn)) ...
...
(not (= xn-1 xn))
)
Note that the negation of this is a disjunction of equations. owl_Property should be read as shorthand for the union of
owl:DatatypeProperty and owl:ObjectProperty.
Unlike the RDFS translation, this translates entire RDF subgraphs into logical sentences. To achieve a full translation, all
matching subgraphs must be translated, and then any remaining triples rendered into logical atoms using the RDF
translation. Note that a triple in the graph may occur in more than one subgraph; in particular, the owl:onProperty triples
will often occur in several subgraph patterns when cardinality and value restrictions are used together.
Implication: (
antecedent: (and (ppp x
y)(ppp x z))
consequent: (= y z)
Universal )
Quantification
Binding: (
Term: (x owl:Thing)
-or- Term: (y rdfs:Literal)
Term: (z rdfs:Literal)
)
Implication
antecedent: (and (ppp x y)(ppp
x z))
consequent: (= y z)
RDFsubject (lll-1)
RDFpredicate
(rdf:rest)
RDFobject (lll-2)
… …
RDFsubject (lll-n)
RDFpredicate
(rdf:rest)
RDFobject (rdf:nil)
RDFsubject (lll-1)
RDFpredicate
(rdf:rest)
RDFobject (lll-2)
… …
RDFsubject (lll-n)
RDFpredicate
(rdf:rest)
RDFobject (rdf:nil)
RDFsubject (lll-1)
RDFpredicate
(rdf:rest)
RDFobject (lll-2)
… …
RDFsubject (lll-n)
RDFpredicate
(rdf:rest)
RDFobject (rdf:nil)
RDFsubject (lll-1)
RDFpredicate
(rdf:rest)
RDFobject (lll-2)
… …
RDFsubject (lll-n)
RDFpredicate
(rdf:rest)
RDFobject (rdf:nil)
RDFsubject (lll-1)
RDFpredicate
(rdf:rest)
RDFobject (lll-2)
… …
RDFsubject (lll-n)
RDFpredicate
(rdf:rest)
RDFobject (rdf:nil)
In addition, depending on the dialect of OWL (OWL DL or OWL Full) in question, certain hierarchical axioms are
assumed, which enforce the distinction between owl:ObjectProperty and owl:DatatypeProperty, for example. For OWL
DL, they also enforce the strict segregation between classes, properties, and individuals. These are summarized below for
comparison purposes.
------------------------------------------------------------------
------------- Conversion of RDF Ressources -----------------------
------------------------------------------------------------------
--------------------------------------------------------------------------
---------------- Axioms when embedding triples ---------------------------
--------------------------------------------------------------------------
-------------------------------------------------------------------
--- Constructor operations for main CL concepts -------------------
-------------------------------------------------------------------
constructor LogicalName(lname:String) {
name := lname;
}
constructor UniversalQuantification(names:Sequence(String),s:Sentence) {
boundName := names->object(n) LogicalName {name:=n;};
body := s;
}
constructor Biconditional(left:Sentence,right:Sentence) {
lvalue := left;
rvalue := right;
}
constructor AtomicSentence(pName:String,args:Sequence(Any)) {
predicate := new LogicalName(pName);
arguments := args->collect(a |
if a.isKindOf(String) then new LogicalName(name=a)
else a endif);
}
This annex includes several libraries: (1) an M1 library to be used with the RDF metamodel, (2) an M1 library to be
used with the OWL metamodel in addition to the RDF library, (3) a model library to be used with the RDF profile,
and (4) a model library for use with the OWL profile in addition to the RDF profile model library.
A subset of the XML Schema Datatypes, specified in, are also available for use in RDF. We provide these in a
separate M1 package. All others are considered unsuitable for use with RDF and should not be used.
Table A.2 - Foundation Library (M1) Defining XML Schema Datatypes For Use with RDF
Table A.3 - Foundation Library (M1) for Use with the OWL Metamodel
versionInfo OWL::OWLBase::OWL
AnnotationProperty
• The first column, M1 Object, represents the element in the model library being described.
• The second column, Base Class & Stereotype, the base class is the UML metamodel element that the M1 Object
is an instance of, and the stereotype, if any, is the stereotype applied to the M1 object.
• The third column, Parent, represents the classifier that generalizes the M1 object if the M1 object is itself a
classifier.
• The Properties column provides UML properties of the M1 object if that object is a classifier.
• Finally, the Description, Constraints column describes the M1 object and identifies additional constraints on that
object, if any.
Table A.4 - Foundation Library (M1) for Use with the RDF Profile
Table A.5 gives a foundation library defining the set of XML Schema Datatypes that may be used with the RDF and
OWL Profiles. All others are considered unsuitable for use with RDF and should not be used.
Table A.6 - Foundation Library (M1) for Use with the OWL Profile
B.1 Overview
UML is considered a basic conceptual modeling language from an ODM perspective. It is frequently used for this purpose,
and is also critical for leveraging existing artifacts as a basis for ontology modeling, either through migration to one of the
ontology-specific languages represented in the ODM, or integration with other components represented in these languages.
Many resources that may be leveraged for ontology development are modeled not in UML, but in one of the dialects of the
Entity-Relationship system. The ODM team considered including an ER metamodel, but in the end did not do so for several
reasons: (1) there is no existing ISO or other standard reference for ER (as there is for each of the other conceptual modeling
languages included herein), (2) there are many “dialects” for Entity Relationship Modeling implemented by various tools,
without discriminating features that might be useful if implemented in an ODM conceptual ER metamodel, and (3) we believe
that the best place for developing such a metamodel is the upcoming information modeling effort that will ultimately replace
the current Common Warehouse Metamodel (CWM).
• ER-style modeling is sufficiently similar to logical modeling in UML that providing an appendix describing a general
mapping strategy from ER to UML and ODM would be useful.
This informative annex shows the relationship between common ER constructs and comparable UML constructs. The only
aspect of ER modeling without a close correspondence to UML is the concept of identifiers. Here, we describe an optional
package sufficient to represent ER identifiers.
• A composite attribute has a domain corresponding to a type which itself has attributes (in UML).
• A relationship which can have attributes, or itself participate in other relationships, corresponds to an association class.
• Total participation of an entity playing a role corresponds to a minimum multiplicity greater than 0 in the
corresponding property.
• Partial participation of an entity playing a role corresponds to a minimum multiplicity of 0 in the corresponding
property.
• Cardinality ratio of ‘many’ corresponds to a maximum multiplicity of ‘*’ in the corresponding property.
• Min-max notation for cardinality constraints corresponds approximately to multiplicity notation in UML, with slight
variation. In ER, the constraints refer to the number of instances of the entity playing the role that can appear in the
relationship set. In UML, the multiplicities refer to the number of instances of the class that is the type of the property
that can be associated with a fixed collection of instances for the other memberEnds. So for a binary relationship, the
min-max cardinality corresponds to the multiplicities for the opposite property. For relationships with degree greater
than two, there is no simple correspondence between ER min-max cardinality constraints and UML multiplicities.
B.4 Generalization
The enhanced ER (EER) system has a generalization/specialization mechanism that corresponds to that in UML. The
disjointness and completeness constraints for specialization correspond respectively to the isDisjoint and isCovering attributes
of a GeneralizationSet in the UML PowerTypes package.
B.5 Identity
The major feature of ER modeling lacking in UML is the concept of identity. The MOF has a primitive identity construct, the
isID attribute of Property in the Identities package, but UML does not support identity at all.
• An entity instance can be identified by an attribute (key), or by a combination of attributes (compound key).
• An entity instance can be identified by the key of another entity it has a relationship with. For example, in a dialect of
ER in which relationships cannot have attributes, that a student is given a grade in respect of enrollment in a course can
be modeled by treating the enrollment as an entity identified by the keys of the student and course entities it is related
to.
• In the special case of a weak entity, an instance of an entity is identified by a compound of local attributes (partial key)
and the key of another (identifying or owner) entity it is in an identifying relationship with.
Id e n t ifie r
+ id e n t ifie r
0..n 0 . . n + id e n t ifie r
I d e n t if ie rC la s s
I de n t if ie rP r o p e rt y
+ id e n t ifi e dC la s s 1 + id e n t ify in g P ro p e rt y
C la s s 1 . . n {o rd e re d }
P ro p e rt y
B.5.1 Identifier
Description
Connects a class with one or more properties constituting a (possibly compound) key for the class. An instance of Identifier is
identified by the property identifiedClass together with name from NamedElement. If there is only one instance of Identifier
associated with an instance of Class, then name can be absent.
Attribute
• No additional attributes
Associations
• identifiedClass [1] the class identified.
• identifyingProperty [1..n] the collection of one or more properties constituting the identifier.
Constraints
Identifier has a name if its identifiedClass has more than one identifier.
context Identifier inv:
(self.identifiedClass.identifier->sizeOf()>1)implies (self.name->
exists(n : string | (self.identifiedClass.identifier.name->
forAll(m: string | m = n implies
(self = self.identifiedClass.identifier))
)
)
)
If a Class and Identifier are fixed, we have a set of Property. It therefore makes sense to profile Identifier as an extension of the
metaclass Property, as shown in Figure B.2.
Tagged Values
• alt : string - name of instance of alternative identifier if there are more than one identifiers for a given class.
B.7 Example
We show an example of use of identifiers, employing the notation specified in Figure B.2, in Figure B.3. The application is
keeping track of results in a sporting competition like the Olympics.
Team and Event are identified by single attributes: country for Team and eID for Event.
Competitor has a single composite identifier, the attribute cName and the property team. This identifier carries the tag ‘a’ for
alt.
CompetesIn has no identifier. Instances are identified by OID, as is usual for UML classes. It could, however, be identified by
the composite of the properties competitor and event.
The subclass MedalAwarded of CompetesIn does have an identifier, the attribute medal and the property event of its superclass
CompetesIn. This identifier carries the tag ‘b’ for alt.
The subclass MedalWinner of Competitor has an additional identifier, carrying tag ‘c’ for alt. Besides the identifier inherited
from its superclass Competitor, an instance of MedalWinner is identified by the property wins. So a medal winner is identified
by the identifier of MedalAwarded, which is the medal and the event.
Team Event
<<Ident ifier>> count ry : string <<Identifier>> eID : String
+team 1 +event 1
<<Identifier alt = a>> <<Identifier alt = b>>
MedalK ind
This annex provides an introduction to Description Logics through the elaboration of an exemplar Description Logic Meta-
Model.
C.1 Introduction
The Description Logic (DL) meta-model defines a basic, minimally constrained DL. In use, DLs are typically found in the
Knowledge-Base of a Knowledge Representation System, as shown in Figure C.1.
TTBBox
ox
DDescription
escription
Language
RReasoner
easoner
L anguage
A
ABBox
ox
K now ledge B ase
K now ledge R epresentation S ystem
Figure C.1 - Knowledge Representation System
2. Assertions, which are named individuals expressed in terms of the vocabulary, called the “ABox.”
3. Description Language that define terms and operators for build expressions.
Note that the TBox and ABox elements represent two separate meta-levels in the application domain.
instantiates
+instances
0..n Term
1 +terminology
TBox Identifier : String
containment
1 +content 0..n
ABox {redefines}
containment Instance
1 +content 0..n
C.2.1 TBox
Description
A TBox contains all of a DL model’s terminology. The TBox may include Terms and any of the sub-classes of Term. Note that
this includes Instances to allow supporting predefined, delineated instances as ‘special terms’ in the ABox. An example of this
would be OWL Thing.
Associations
• Containment.content[0..n]: Term – the terminology contained in this TBox.
• instances[0..n]: ABox – the TBox that uses terms and instances from this TBox.
• terminology[1]: TBox – the TBox that contains the terminology used by this TBox (or ABox)
C.2.2 ABox
Description
An ABox contains all of a DL model’s instances. The ABox extends TBox and restricts its content to be only the sub-classes
Instance.
Associations
• Containment.content[0..n]: Instance – the instances contained in this ABox, redefining containment from TBox.
Semantics
All the instances in an ABox are expressed using the terminology from exactly one TBox.
Description
Element is an abstract base class of all atomic components in a DL as seen in Figure C.3. It defines the notion of unique
identity so that references may be made to elements using that identifier.
ABox
Elements
Concept Role
1 1
+obje ct +subject
+member
+member
0..n ob ject sub ject 0..n
0.. n 0.. n {uniq ue member.Uni queIdentifier}
Individual Assertion
Attributes
• UniqueIdentifier: String - Uniquely identifies an Element and all Elements are identified by a single value. That is if
UniqueIdentifiers of two Elements are different, then the Elements are different. Note that this is different than URIs.
UniqueIdentifier is required.
C.3.2 Concept
Description
Concept is a set of Instances that are define as having something in common.
Associations
• isA.member: Individual[0..n] -- The set of Individuals that are the extent of the concept.
C.3.3 Instance
Description
Instance provides an abstract base class for all ABox constructs. Instance is a specialization of Term.
Similar Terms
Object, Instantiation
C.3.4 Role
Description
A Role is a set of binary tuples, specifically (subject, object), that asset that this role for subject is satisfied by object. Role is a
specialization of Element.
Similar Terms
Association, Attribute, Property, Slot
Associations
• isA.member: Assertion [0..n] -- The set of Assertions that are the extent of the concept.
C.3.5 Individual
Description
Individual is an instance of a Concept. An Individual is a specialization of Instance
Similar Terms
Object
Associations
• isA.type: Concept[1..n] – The set of concept sets that has this individual as a member.
C.3.6 Assertion
Description
Assertions are the specific binary tuples that are instances of Roles. An Assertion is a specialization of Instance.
Associations
• subject.subject: Instance[1] – The Instance that is the subject of the assertion.
• object.object: Instance[1] – The Instance that is the object of the assertion.
• sA.type: Concept[1..n] – The set of Roles that has this assertion as a member.
• predicate: Instance[1] – A derived reference to the Role which this assertion is an instance of. (Not shown in diagram.)
C.4 Datatypes
C.4.1 Datatype
Description
A Datatype is a specialization of Concept. Datatypes are those concepts whose members have no identity except their value,
that is the members of a datatype are literals, as shown in Figure C.4. Datatype may represent primitive types, for example
integer, string, or boolean; or user defined type, for example time-interval or length-in-meters.
Concep t
DataType
+member
{unique member.UniqueIdentifier} 0..n
Literal
value : Any
Associations
• isA.member: Literal[0..n] – the set of literals that are members of this datatype.
C.4.2 Literal
Description
Literals are the specification of instances of datatypes. The UniqueIdentifier inherited from Element is for a literal, uniquely
defined by the literal’s value itself.
Associations
• type: Datatype[0..n] – the possibly empty set of datatypes in which this literal is a member.
Constraints
Restricts range of Concept.type to a set of Datatypes.
Semantics
Element.UniqueIdentifier has a functional relation with Literal.value.
C.5 Collections
C.5.1 Collection
Description
A Collection is a specialization of Concept. Collection allows instances to be brought together as a group and referenced as a
single collective. The class diagram for Collection is shown in Figure C.5.
Concept
Collection
1..n
+type
Inst ance
Set List
0..n
+c ontains
Individual
+member
0..n
Ext ent
Associations
• isA.member: Extent[0..n] – The set of instances of a particular kind of collection.
C.5.2 List
Description
List is a specialization of Collection. List requires that the member instances that are in the collection are ordered in a user
defined way.
Semantics
For all ai , aj members of the list, there is a comparator function C() such that C(ai) < C(aj) if i < j
C.5.3 Set
Description
Set is a specialization of Collection. Set requires that the member instances in the collection are unique.
Semantics
For all ai , aj members of the list, there is a identity function I() such that I(ai)=I(aj) iff i = j
C.5.4 Extent
Description
Extent is a specialization of Instance. Extent is the set of all instances of a collection of a particular type, for example the set of
all Alphabetical-Lists.
Associations
• containment.contains: Instance[0..n] – Those instances that are in this instance of a collection.
• isA.type: Collection - The set of collection sets that has this extent as a member.
A number of common expression constructors, shown in Figure C.6, are provided as specializations of Constructor.
Expres sion
+constructor
1
Constructor
C.6.1 Term
Description
Terms are the components used to build expressions. They are an abstract root class of most DL classes, excluding only ABox,
TBox, and Constructors.
Similar Terms
Word, Component
Attributes
• Identifier: String [0..1] – An optional identifier for this term.
C.6.2 Expression
Description
Expressions are the representation of the DL Knowledge Base Description Language, shown in Figure C.1. Expressions are an
extension of Term and are also constructed from Terms using Constructors. Thus allowing arbitrarily complex expressions to
be created.
Associations
• term_1: Term[1] – The required term for the constructor.
C.6.3 Constructor
Description
A Constructor is an operator that is used to build expressions. A Constructor may be either monadic or dyadic.
Note that individual specializations of constructor may have additional semantics and restrictions that are not elaborated here.
Similar Terms
Operator
Semantics
• Monadic constructors have term_2.multiplicity = 0
C.6.4 Intersection
Description
The Intersection constructor is a dyadic constructor. It results in the set of instances that are members of both the left-hand
term and the right-hand term.
C.6.5 Negation
Description
The Negation constructor is a monadic constructor. It results in the set containing all instances not contained in the right-hand
term.
C.6.6 Union
Description
The Union constructor is a dyadic constructor. It results is the set containing any instance that is a member of either the left-
hand or right-hand term.
Description
A Quantifier is a specialization of Constructor. It is a monadic constructor. They are operators that bind the number of a role’s
assertions by specifying their quantity in a logical formula.
C.6.8 ForAll
Description
ForAll is a specialization of Quantifier. ForAll specifies that all members of term_1 must have the binding value for the
specified role.
C.6.9 Existential
Description
Existential is a specialization of Quantifier. Existential specifies that at least one member of term_1 has the binding value for
the specified role.
C.6.10 NumberRestriction
Description
NumberRestriction is a specialization of Quantifier. NumberRestriction specifies that a specified number of members have a
value for the specified role, similar to cardinality or multiplicity.
Further specializations of NumberRestriction may include upper bound, lower bound, and exact number specifications.
C.6.11 Definition
Description
Definition is a specialization of Constructor. It is dyadic. Definition is used in axioms to define the left-hand term as exactly
the right-hand term.
C.6.12 Implication
Description
Implication is a specialization of Constructor. It is dyadic. Implication is a logical relationship between the term_1 and term_2,
that states term_2 is true if term_1 is true.
C.6.13 Inclusion
Description
Inclusion is a specialization of Constructor. It is dyadic. Inclusion is a relation between the term_1 and the term_2 that states
all members of the first are also members of the second. Inclusion is similar to sub-types, in that all members of a sub-type are
included in the super-type.
A PersonalCar is a Car
that is owned by a person.
PersonalCar :
Concept
Car is a type of Vehicle.
e1 : Expressi on : De finition
e2 : Expression : Intersection
e4 : Expression : Existential
Car : Concept
'owns' is more
Ca rl : Individual
Carl owns a car that is red association-like.
and another car that is blue. subject
object
e : Extent
content
content
type member
Ca r : Co ncept thing2 :
thing1 :
Individual
Individual mem ber type
su bjec t
su bjec t 'color' is more
attribute-like
object object
red : t ype member blue :
Color : DataType
Literal Literal
member type
co ntain men t
Te rm 0.. n +content
TB ox
Identif ier : String
1
0..1 +term_2
1 +term_1
TBox
Ele ments Ex pres sion
Element Constructor
UniqueIdentif ier : String
ABox +constructor1
Elements
Concept Role
1.. n 1.. n
+ty pe
+ty pe
+content
DataTy pe Collection 0..n 1 ABox
Ins tan ce
isA containment
{redef ines}
0..n 1.. n
0..n 1 1
+ty pe +ty pe
+subject +object isA
+contains
+member
0..n
isA
isA
Indiv idual subject object +member
0..n 0..n 0..n
Assert ion
+m ember
+member
0..n 0.. n
containment
Literal Extent
v alue : Any
D.1 Extendibility
From the Usage Scenarios and Goals of Chapter 7, there is an enormous variety of kinds of application for ontologies. They
can be used at design time only or at both design and run time. They can be schemas only or involve both schemas and
instances. Their structure can be imposed from outside their domain or can emerge from the activities of interoperating parties.
And so on.
Many of these kinds of application have special requirements that are common to many application instances but that are not at
all universal. The ODM specification has limited its efforts to the most general structural issues.
However, in practice one can envisage particular extensions to the general structures that support significant numbers of
application instances, which would be published by third parties outside the OMG ODM process but that would be consistent
with the ODM, in much the same way as the Dublin Core metadata standard is published as an RDFS namespace. These
extensions would use the MOF Package as a medium.
We will illustrate this facility with three examples, all of which use model elements from OWL packages so are seen as
extending OWL. The examples are respectively of metaclass taxonomies, semantic domain instance models, and n-ary
associations.
O W L C la s s
C o u n t a b le C la s s B u lk C la s s
This is the sort of enhancement that would be done for UML using profiles. OWL does not have a profile mechanism.
However, OWL Full supports a somewhat analogous facility, that of defining subclasses of the metaclass owl:Class. Since
owl:Class is an instance of OWLClass, it is possible to declare instances of OWLClass that are subclasses of owl:Class. So a
This same approach can be used with other taxonomies of metaclasses, for example the taxonomy of endurants and perdurants
proposed in the DOLCE system [DOLCE].
It is possible to develop these packages as extensions to one of the metamodels, in this case OWL, then use the ODM mapping
facilities to migrate it to any of the other metamodels. Note that the MOF permits multiple inheritance, so that several such
extensions can in principle be used simultaneously. However, the MOF Instances Model does not support an object having
multiple classifiers. This specification has recommended that the MOF specification be amended to remove this limitation,
which strongly impacts the ODM.
A feature of OWL is that properties are by default defined globally, with range and domain both Thing. This makes it possible
to represent mereological relationships as instances of property. Instances of metaclasses can be modeled using instance
models, a facility of MOF 2.0. For example, Figure D.2 defines a version of isPartOf which is transitive, every part belongs to
at least one whole (and by transitivity to all the wholes up the chain), and a part cannot exist without its corresponding whole.
This kind of part-of relation could be suitable for modeling say the Olympic family. An athlete is part of an event (if a
competitor), an event is part of a sporting program, a sporting program is part of the Olympics of a given Olympiad, and
anyone who competes in any event in any program in any Olympics is a part of the Olympic family. But an Olympics cannot
exist without at least one program, a program must have at least one event, and an event at least one competitor.
isPartOf: OWLTransitiveProperty
OWLminCardinality
:OWLTran sitivePro perty :OWLRestriction
OWLonProperty 1:RDFSLiteral
OWLminCardinality
There are a large number of varieties of mereotopological relationships [WinChafHerr], including those specified in UML.
They could be catalogued and published as a package, perhaps with specialized software. The W3C Semantic Web Best
Practices and Deployment Working Group (SWBPD) is considering this problem with respect to OWL. A very preliminary
report is [PartWhole].
A property can either necessarily have a metaproperty, or can possibly have a metaproperty, or can be declared to necessarily
not have a metaproperty. For example, a property necessarily identifying instances of a class can necessarily not be a rigid
property for that class.
A metamodel for this system of metaproperties as a quaternary association is shown in Figure D.3.
WithRespectTo
WithStatus
+metap +status <<enumeration>>
0..n Metaproperty
St atusKind
+metaproperty 0..n 1
Property (from OWL) 1 On 0..n 0.. n
+metap +metap
+property
Tak esValue
1 +prop
<<enumeration>>
MetapropertyKind
Most of the metamodels in the ODM permit n-ary associations, except RDFS/OWL. But an n-ary association can be
represented as a class with n binary properties. To be consistent with the previous examples, a possible package to model
metaproperties in Figure D.4 extends the OWL metamodel. Note that the metaproperty is modeled as a subclass of OWLClass.
This can facilitate mapping from OWL to an n-ary association or equivalent in another metamodel. The class of
metaproperties is a subclass of NAryProperty. This approach is consistent with the more general pattern discussed by the
SWBPD in the preliminary report [Nary].
We need an additional constraint that all the properties implementing a given n-ary property have the central class as their
domain.
context NAryProperty inv:
self.property.RDFSdomain->(forall d | d = self)
In developing the mappings for the various ODM languages, the team concluded that the mappings we specify cannot in
practice be normative.
In our discussion in Section 10.2.3, for example we see that there are two different ways to map n-ary associations from UML
to OWL, depending on whether we take OWL Full or OWL DL as target. In Section 10.2.2, we note that OWL has a
mandatory universal superclass (owl:Thing), which can map to a universal superclass in UML, but this is contrary to normal
practice in UML modeling. A particular project might analyze the uses of universal properties in the OWL source model and
choose to declare a number of more general but not universal superclasses in the UML target.
In the W3C Semantic Web Best Practices and Deployment task force’s report on Topic Map mappings [RDF/TM], the point is
made several times that there are different ways to map particular structures, and that each way has its advantages and
disadvantages. In any particular project, design decisions will be taken in favor of advantages and against disadvantages so
different projects will map in different ways.
There are several kinds of problems. One we can call structure conflation, where two constructs in one system map to a single
construct in the other. In this case, a general-purpose mapping doesn't round trip. UML binary associations and class-valued
attributes map to OWL properties, for example. In topic maps, three different kinds of identifiers map to one kind in OWL.
But there is nothing to stop a particular project from specifying naming conventions so there is a record in the target of what
construct the source was, and from maintaining that convention in subsequent development.
A second kind of problem we will call structure loss. Here a complex construct is mapped to a collection of simpler constructs.
There is insufficient information in the target metamodel for a general mapping to map collections of simple constructs to
complex constructs in the source metamodel. Examples here are UML N-ary associations and association classes, which get
mapped to a class and a collection of properties. In Topic Maps, the Association construct is typed itself and has N typed roles.
The association maps to a class and the typed roles to properties. It is in general impossible to reliably map the reverse.
But again, there is nothing to stop a particular project from using naming conventions or annotations to retain a memory of the
structure, and maintaining those conventions in subsequent maintenance so as to be able to reverse map.
Alternatively, a TM project could decide to limit itself to binary associations, making possible mapping associations directly to
properties in that particular case.
The third kind of problem we will call trapdoor mappings, where a kind of construct in the source is mapped to a very specific
arrangement of a general structure in the target. The analogy is with cryptography, where the encryption function takes any
plaintext into an encrypted text, but almost no encrypted texts map back to plain text.
In topic maps, this occurs with the mapping of scope and variant names to specific properties in OWL identified with TM
URIs. OWL properties map to TM associations with specific roles named with OWL URIs. Unless the source for a reverse
mapping happened to maintain these conventions, it would be impossible to reverse in a sensible way.
The fifth kind of problem is what we will call incompatible structural principles. The different metamodels are organized very
differently. UML is organized around classes, with instances as subordinate objects. OWL has both classes and individuals
typed only by a universal superclass. In Topic Maps, a Topic instance can be either typed or not. But a particular project might
use a particular discipline in its use of these structures leading to mappings not otherwise feasible.
In practice, the mappings provided in the ODM can be useful, though. First, they show feasibility of one set of design choices
for the mappings, providing a baseline from which a particular project can vary. Second, they bring clearly to the fore the
detailed relationships among the metamodels. These relationships can help those who understand one of the target languages
to come to an understanding of the others. UML is similar to ER, but both are very different from RDFS/OWL, and all are
quite different from TM. CL has far greater functionality than any of the others.
So although normative mappings are not feasible, we argue that the mappings presented have strong informative value.
This annex provides alternate approaches for modeling several aspects of RDF and OWL that may not be readily accessible to
tools due to the MOF multiple classification issue #9466. They include:
• Access to blank node identifiers from other constructs such as OWL restriction classes.
• Access to type information for multiply classified OWL properties (e.g., functional and object).
• Access to type information for multiply classified concepts in OWL Full in general (e.g., concepts that are both classes
and individuals, depending on role).
The workarounds provided below are non-normative, however may be used by vendors claiming ODM compliance until the
MOF issue is resolved.
UniformResourceIdentifier
name : string
0..1
+uri
URIForURIReference
+uriRef
0..*
+graphName
URIReference +uriRef URIRefForResource
0..1
0..*
0..*
+nameForReification
SubjectForStatement
Reification URIReferenceNode
+reifiedStatement +subjectStatement
0..* +RDFsubject +resource
NameForGraph 0..*
0..1 0..1
RDFStatement
ObjectForStatement RDFSResource BlankNode
i sReifiedOnly : Boolean [0..1]
i sReified : Boolean [0..1] 0..* 0..1 nodeID : String [0..1]
+objectStatement +RDFobject
1..* 0..*
+statement +predicateStatement
RDFSLiteral
StatementForGraph Predic ateForStat ement lexicalForm : string
RDFProperty
+graph
1..* 0..1
+RDFpredicate
RDFGraph
0..1
+namedGraph
As shown in Figure F.1, the change necessary to work around the multiple classification issue with respect to blank nodes is
simply to promote the node identifier to RDFSResource as an optional attribute at the higher level.
Attributes
None
Attributes
• nodeID: String [0..1] - is a placeholder for an optional blank node identifier.
Constraints
[1] context RDFSResource inv:
self.nodeID->notEmpty() implies self.oclIsTypeOf(BlankNode)
RDFProperty
+OWLequivalentProperty
0..* EquivalentProperty
OWLAnnotationProperty OWLOntologyProperty Property
isDeprecated : Boolean [0..1]
isFunctional : Boolean 0..*
... +equivalentProperty
+OWLinverseOf
0..* InverseProperty
OWLDatatypeProperty OWLObjectProperty
isInverseFunctional : Boolean
isSymmetric : Boolean 0..*
isTransitive : Boolean +inverseProperty
As shown in Figure F.2, a number of changes are required to the OWL properties definitions given in Chapter 11, in order to
support multiple classification of properties in OWL. These changes consist primarily of eliminating certain property
subclasses and replacing them with attributes on the requisite parent classes.
Thus, classes defined in Section 11.4.1, “FunctionalProperty,” Section 11.4.2, “InverseFunctionalProperty,” Section 11.4.8,
“SymmetricProperty,” and Section 11.4.9, “TransitiveProperty,” are not required, and instead the following attributes must be
added to the definitions given in Section 11.4.7, “Property,” and Section 11.4.5, “OWLObjectProperty,” respectively.
Attributes
• isInverseFunctional: Boolean [0..1] - indicates whether or not an object property is inverse functional.
Attributes
• isFunctional: Boolean [0..1] - indicates whether or not an object or datatype property is functional.
However, as discussed in Section 6.1, “Changes to Adopted OMG Specifications” there is a limitation in the MOF2 semantic
domain (instances) model that requires that an InstanceSpecification be associated with exactly one classifier. This makes it
impossible to have an object as an instance both of Individual and OWLClass, for example. Note that the UML Infrastructure
Instances Model does permit an InstanceSpecification to be associated with more than one classifier.
This problem is handled in UML by defining specific intersection classes where needed, for example AssociationClass. The
modifications provided in the sections that follow provide additional attributes on OWLBase metamodel classes as well as
definitions of new intersection classes required as a work-around to implement OWL Full. When a future revision of MOF
relaxes the semantic domain model to permit multiple classifiers, these additional derived attributes and the OWLFull Package
implementing the intersection classes this package will become superfluous.
Figure F.3 provides a revised OWL Universe diagram, including the additional derived attributes required on the OWLClass
and Property metaclasses.
RDFSResource
nodeID : String
OWLClass Property
isDeprecated : Boolean [0..1] Individual isDeprecated : Boolean [0..1]
/ isClassKind : OWLClassKind isFunctional : Boolean
/ hasRestrictionKind : OWLRestrictionKind / isObjectProperty : Boolean
/ isDatatypeProperty : Boolean
In Figure F.4, the set of additional intersection classes as well as related enumerations to support OWL Full in light of the
MOF issue are shown.
F.3.1 IndividualOWLClass
Description
Intersection of Individual and OWLClass
Attributes
None
Associations
• Specialize Class Individual
Constraints
None
Semantics
Conjunction of semantics of Individual and of OWLClass.
Description
Intersection of Individual, Property, and OWLClass.
Attributes
None
Associations
• Specialize Class IndividualProperty
Constraints
None
Semantics
Conjunction of semantics of Individual, Property, and of OWLClass.
F.3.3 IndividualProperty
Description
Intersection of Individual and Property
Attributes
None
Associations
• Specialize Class Individual
Constraints
None
Semantics
Conjunction of semantics of Individual and of Property.
Description
As in OWLBase
Attributes
• isClassKind : OWLClassKind [0..1] - partitions OWLClass into the subclasses defined in OWLBase.
Associations
No additional associations
Constraints
context OWLClass inv
(self.classType = isComplementClass) implies self.oclIsTypeOf(ComplementClass) and
(self.classType = isIntersectionClass) implies self.oclIsTypeOf(IntersectionClass) and
(self.classType = isUnionClass) implies self.oclIsTypeOf(UnionClass) and
(self.classType = isEnumeratedClass) implies self.oclIsTypeOf(EnumeratedClass) and
(self.classType = isOWLRestrictionClass) implies (self.oclIsKindOf(OWLRestriction) and
self.restrictionType->notEmpty())) and
(self.restrictionType->notEmpty() implies self.classType = isOWLRestrictionClass) and
(self.restrictionType = isHasValueRestriction) implies self.oclIsTypeOf(HasValueRestriction) and
(self.restrictionType = isAllValuesFromRestriction) implies
self.oclIsTypeOf(AllValuesFromRestriction) and
(self.restrictionType = isSomeValuesFromRestriction) implies
self.oclIsTypeOf(SomeValuesFromRestriction) and
(self.restrictionType = isCardinalityRestriction) implies
self.oclIsTypeOf(CardinalityRestriction) and
(self.restrictionType = isMaxCardinalityRestriction) implies
self.oclIsTypeOf(MaxCardinalityRestriction) and
(self.restrictionType = isMinCardinalityRestriction) implies
self.oclIsTypeOf(MinCardinalityRestriction)
Semantics
Same as in OWLBase
F.3.5 OWLClassKind
Description
OWLClassKind is an enumeration of the following literal values.
• isComplementClass, isEnumeratedClass, isIntersectionClass, isOWLRestrictionClass, isUnionClass
F.3.6 OWLRestrictionKind
Description
OWLRestrictionKind is an enumeration of the following literal values:
Description
As in OWLBase
Attributes
• isObjectProperty : Boolean [1] - true if instance is an instance of OWLObjectProperty
Associations
• no additional associations
Constraints
context OWLFullProperty inv:
(self.isObjectProperty or self.isDatatypeProperty) and
self.isObjectProperty implies self.oclIsTypeOf(OWLObjectProperty) and
self.isDatatypeProperty implies self.oclIsTypeOf(OWLDatatypeProperty)
Semantics
Same as in OWLBase
F.3.8 PropertyOWLClass
Description
Intersection of Property and OWLClass
Attributes
None
Associations
• Specialize Class Property
• Specialize Class OWLClass
Constraints
None
Semantics
Conjunction of semantics of Property and of OWLClass.
IndividualOWLClass can be used as a metaclass to specify classes of classes. For example, the US Department of Labor
Standard Industrial Classification system (SIC) is used to classify enterprises. Each classification can be viewed as a class
whose instances are enterprises. However, there are a large number of such SIC classes. For some applications, it might make
sense to model the collection of SIC classes as instances of a class SICClass. This would then enable one to model a datatype
property, say numberOfEstablishments, whose domain is SICClass, whose range is integer, and whose semantics is “number
of establishments classified by an instance of SICClass.”
IndividualProperty can be used to specify a class whose instances are properties. For example, a machine learning application
building a decision tree from a training set to classify a stream of cases often uses an algorithm related to ID3. ID3 starts with
a large number of properties and builds a decision tree by successive choice of properties depending on how much the property
contributes to classification (entropy gain). This is naturally modeled using a class whose instances are the properties.
IndividualProperty can also be used to specify a property whose domain is a class of properties. The entropy gain property
used in ID3 is a good example.
IndividualPropertyOWLClass can be used to specify a class whose instances are association classes.
Package
related elemen t
child
parent
Vocabu lary element
Business domain Nomenclature na mespace owned element
Definition :string
Example :string elemen t
namespace
Usag e :string
ta xonomy gloss ary
Taxonomy Glossary
owned e lement
Language
/na mespace concept te rm
/namesp ace Concept narrowerTerm Term synonym
/owned elemen t
/owned element
The Business Nomenclature (BN) metamodel from the CWM standard is shown in Figure G.1. The metamodel has been
redrawn and slightly modified to simplify the picture without losing anything essential:
• The aggregation notation on the associations whose source is Nomenclature have been removed.
• The cardinality constraints have been omitted.
• Two associations at Concept and Term derived from element/relatedelement have been omitted.
In this note we show that BN can be comfortably represented as an M1 model in place of its native M2 model, and in the three
key ODM metamodels: UML, OWL, and Topic Maps.
• The terms represented in rectangles (the upper rectangle where two rectangles are conjoined) are natively MOF
classes. To see BN as a UML model, we interpret the rectangles as UML Classes.
• The terms represented as attached to ends of unadorned lines are names of pairs of MOF associations and their
opposites. In the UML interpretation, these are interpreted as UML associations and their opposites.
• Terms represented in the lower of two attached rectangles are names of MOF attributes. In the UML interpretation,
these are interpreted as UML attributes.
The systems of lines terminating in an arrow represent the MOF subclass relationship, with the MOF classes at the unadorned
ends being MOF subclasses of the MOF class at the end with the arrow. In the UML interpretation, the system of lines
represents the UML subclass relationship.
Similarly, MOF cardinality constraints (not shown) would be interpreted as UML cardinality constraints.
We now want to see BN as an OWL model. Note that OWL does not have a native graphic notation. However, the mapping
from UML to OWL in Chapter 16 allows us to interpret the MOF diagram as a visualization of an OWL ontology:
• UML associations are pairs of OWL object properties with their inverses.
In a similar way, by following the mapping in Chapter 17, Mapping Topic Maps to OWL, the BN metamodel can be
interpreted as a Topic Map:
• OWL classes are Topics.
• OWL object properties are TM Topics that are types of associations. The names of the ends are interpreted as TM
Topics that are types of association roles.
• OWL cardinality constraints are not mapped, since TM does not support a comparable feature.
• An M0 instance of the UML model would be exactly the same thing using the UML instance model rather than the
MOF instance model.
• The INSPEC thesaurus is a Topic Map is a collection of instances of Topic linked by instances of Association. (The
Topic Maps metamodel is a mixture of M2 and M1 level constructs, so some of the instances of Topic are M1 and
others are M0.)
Finally, the fact that an M1 instance of BN is identical to an M0 instance of the equivalent UML model suggests that BN is
more appropriately modeled at the UML M1 level than the MOF M2 level. M1 instances of the ODM metamodels can be left
unpopulated if there are no M1 instances of their instances models. BN does not have its own instance model, instead relying
on the MOF instance model, hence the instances models of the other metamodels.
That the ODM casts light on the strategy for modeling other systems suggests a further use for ODM components. In
particular, the component Common Logic has a sound model theory, so that CL can be used to ground other models like SBVR
(Semantics of Business Vocabulary and Business Rules) or PRR (Production Rule Representation).
Mappings are expressed in the MOF Query / Views / Transformations [MOF QVT] specification. Since this is very new, we
present here some key points on QVT Relations that may assist the reader. More detailed points are included as comments
where they appear in the individual mapping chapters.
The other two parts, the enforce and where clauses, carry out the transformation. The enforce clause describes a pattern in the
same way as the checkonly clause, but where the pattern described does not exist in the model, sufficient objects are added to
the model to satisfy the pattern. The where clause indicates further transformations that must be executed by calling other
relations. A transformation is carried out for each set of instantiations of the variables.
The when clause includes calls to relations that are treated as predicates, returning true if the predicates in the checkonly and
when clauses are satisfied, and if the enforce clauses in the relations called in the where clause find that the patterns specified
to be constructed already exist. No work is done via a when clause. The when clause can also contain OCL expressions, which
can also instantiate variables. In the when clause, the various predicates are connected by either semicolon, interpreted as
conjunction, or “or,” interpreted as disjunction. In evaluating a disjunction, each variable instantiation making the disjunction
true is successively generated. OCL functions can be used.
There are two kinds of variables in QVT: a native QVT variable and the variables appearing in iterators in OCL statements.
Native QVT variables have scope the relation they occur in. All variables must be declared as to type, but the declaration can
occur in the checkonly or enforce clauses as well as by specific declaration. A variable cannot be declared in a relation call.
OCL iterator variables have scope as in OCL, namely limited to the subexpression they appear in. But a QVT relation call
containing OCL variables can appear in the body of an iterator.
Relations are executed in two different ways. A top relation is executed by the system. Relations not top are executed by being
called in a where clause. Both kinds of relations can be called in a when clause. The guard patterns in the checkonly and when
clauses control the sequence of evaluation of top relations.
When a relation is called, its parameters are passed as for a normal procedure call. The variables declared in domains in
checkonly and where clauses are treated as formal parameters, associated sequentially with variables in the calling sequence.
Once an object is created, its type is fixed. An object will match a pattern specifying a supertype, but not one specifying a
subtype. Therefore an object must be created with the most specific type applying to it. Properties of the object specified in
supertypes can be added by relations in the where clause, so the common MOF model architecture of abstract classes is
In case a model element (A) depends on another model element (B) (has an association with lower multiplicity greater than 0
at the member end), the mapping of A can be delayed until after the mapping of B by placing the relation mapping B in the
when clause of the relation mapping A.
In case a model element (B) is subordinate to another model element A, the relation mapping B is placed in the where clause
of the relation mapping A, so B is mapped after A. A subordinate model element B is a part of A that makes little sense apart
from A. B often would have an identifier that includes the identifier of A. But the decision to consider one element as
subordinate another is a design choice. There is no absolute criterion.
Four of the five metamodels have a packaging construct. In UML, the packaging construct is called Package, in OWL
OWLOntology, in Topic Maps the Topic Map, and in Common Logic the Module. In these metamodels, structural declarations
and constraints are bounded in scope by the packaging constructs containing them, and by the packaging construct contents
that may be imported into them.
RDFS on the other hand does not have a bounded packaging construct. RDFS elements are instances of Statement, which are
grouped into Graphs, which may optionally be named. But an instance of Graph does not necessarily have any semantic
relevance. In particular, it does not necessarily bound the scope of a structural declaration.
There is a relationship between the Graph metaclass of RDFS and the OWLOntology metaclass of OWL. All OWL
declarations are equivalent to RDF statements, so OWL declarations involve RDF Graphs. However, a given instance of RDF
Graph can contain (parts of) possibly several Ontologies, and a given Ontology can have parts in possibly several RDF
Graphs.
So when performing a mapping using QVT or performing any reasoning task, the repository must make accessible the relevant
packaging structure contents and the contents of imported structures. The computation of patterns and other reasoning
computations are limited in scope to the relevant packaging structure contents. However, in the case of RDFS the application
is responsible for making the relevant RDF Graphs accessible to whatever reasoning mechanisms the repository may be called
upon to perform. The mechanisms for specifying the relevant graphs is outside the scope of the ODM.
There is also a relationship between the population of a model instance accessible to a repository procedure and the MOF
concept of navigability. A process in a repository can link from one object to another via any property, whether designated
navigable or not. Designating a property navigable is an instruction to repository designers to make it easy to find links using
that property, by for example providing indexes. Although using a non-navigable property is legal, it is discouraged on the
grounds that it is not necessarily efficiently supported.
For example, in UML there is no specified property linking an instance of Package to a package that may import it. This
reflects the fact that a package does not necessarily know which other package might import it. However, if the repository is
known to contain the contents of all relevant packages, it is possible to find all packages importing a given package, relative to
the content of the repository.
T
TBox 296
Term 104, 302
Terms and definitions 5
Terms Diagram 101
Text 100
The Description Logics dialect of OWL (OWL DL) 8
The most expressive dialect of OWL (OWL Full) 8
Topic 119
Topic Map 181, 235
Topic Map Metamodel 117
Topic Maps (TM) 7, 9
TopicMap 118
TopicMapConstruct 117
TopicName 125
Traditional First Order Logic (TFOL) 9
TransitiveProperty 85, 92, 197
Triple 35, 36, 37, 39
TypeAble 123
TypedLiteral 43, 50, 140
typographical conventions xii
U
Unified Modeling Language (UML) 7, 9
Uniform Resource Identifier (URI) 9
UniformResourceIdentifier 39, 133
Union 303
UnionClass 74
UniversalQuantification 112
universe of discourse 7
URI reference 39, 40
URIReference 133
URIReferenceNode 41, 137
US Department of Labor Standard Industrial Classification system
(SIC) 323
Usage Scenarios 13, 17