U.S. patent application number 12/186846 was filed with the patent office on 2008-11-27 for method and apparatus for frame-based knowledge representation in the unified modeling language (uml).
This patent application is currently assigned to Sandpiper Software, Inc.. Invention is credited to Mark Eric Dutra, Elisa Finnie Kendall.
Application Number | 20080295068 12/186846 |
Document ID | / |
Family ID | 27734660 |
Filed Date | 2008-11-27 |
United States Patent
Application |
20080295068 |
Kind Code |
A1 |
Kendall; Elisa Finnie ; et
al. |
November 27, 2008 |
METHOD AND APPARATUS FOR FRAME-BASED KNOWLEDGE REPRESENTATION IN
THE UNIFIED MODELING LANGUAGE (UML)
Abstract
According to an embodiment of the present invention, there is
provided a method and system for emulating a knowledge
representation in a Unified Modeling Language (UML) environment. A
Meta-Object Facility metamodel and UML profile are grounded in a
foundation ontology. The elements representing the knowledge
representation ontology are mapped to elements of UML, based on the
grounded Meta-Object Facility metamodel and UML profile, thereby
emulating the knowledge representation in a UML environment.
Inventors: |
Kendall; Elisa Finnie; (Los
Altos, CA) ; Dutra; Mark Eric; (San Jose,
CA) |
Correspondence
Address: |
SCHWEGMAN, LUNDBERG & WOESSNER, P.A.
P.O. BOX 2938
MINNEAPOLIS
MN
55402
US
|
Assignee: |
Sandpiper Software, Inc.
|
Family ID: |
27734660 |
Appl. No.: |
12/186846 |
Filed: |
August 6, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10499961 |
Jun 21, 2004 |
7424701 |
|
|
PCT/US03/04229 |
Feb 12, 2003 |
|
|
|
12186846 |
|
|
|
|
60356611 |
Feb 12, 2002 |
|
|
|
Current U.S.
Class: |
717/104 |
Current CPC
Class: |
G06N 5/027 20130101 |
Class at
Publication: |
717/104 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
Claims
1. A method for emulating frame-based knowledge representation in
unified: Modeling Language (UML), the method comprising: grounding
a Meta-Object Facility (MOF) meta-model and a UML profile in a
foundation ontology, wherein the foundation ontology defines
concepts, relations, individuals, and methods that ground the MOF
meta-model and the UML profile; and mapping elements of the
frame-based knowledge representation to elements of UML based on
the MOF meta-model and the UML profile, wherein the frame-based
knowledge representation describes knowledge using conceptual
definitions and logic sufficient to support automated
reasoning.
2. A system for emulating frame-based knowledge representation in
Unified Modeling Language (UML), the system comprising: a
Meta-Object Facility (MOF) meta-model grounded in a foundation
ontology, wherein the foundation ontology defines concepts,
relations, individuals, and methods that ground the MOF meta-model
and the UML profile; a UML profile grounded in the same foundation
ontology, wherein the UML profile is used to extend a UML language
itself to enable UML tool users to use familiar notation for
ontology modeling purposes; and a logic component, executable on a
processor, to map elements of the frame-based knowledge
representation to elements of UML based on the MOF meta-model and
the UML profile to thereby generate a resulting ontology, and to
act on the resulting UML ontology, wherein the elements of the
frame-based knowledge representation include different frame types
sufficiently specified to enable interference and reasoning.
3. A method for creating an ontology in Unified Model Language
(UML), the method comprising: accepting as input an ontology name
and one or more ontology elements, each ontology element
corresponding to at least one of a term, concept, and relationship
between concepts, the ontology elements forming a detailed
specification of the ontology; generating a logically equivalent
ontology with UML model elements based on a UML profile grounded in
a foundation ontology, wherein the foundation ontology defines
concepts, relations, individuals, and methods that ground a
Meta-Object Facility (MOF) meta-model and the UML profile, wherein
the MOF meta-model is used to represent an abstract syntax of a
particular knowledge representation paradigm or ontology language
to facilitate model interchange purposes, and wherein the UML
profile extends a UML language to enable UML tool users to use
familiar notation for ontology modeling purposes; and presenting
the logically equivalent ontology to a user in a UML
environment.
4. The method of claim 3, wherein said generating the logically
equivalent ontology with Unified Modeling Language (UML) model
elements includes generating a UML package and class for each frame
type of an ontology.
5. The method of claim 3, wherein said generating the logically
equivalent ontology with Unified Modeling Language (UML) model
elements includes a generating UML association for specific
ontology elements.
6. The method of claim 3, wherein said generating the logically
equivalent ontology with Unified Modeling Language (UML) model
elements includes generating a UML operation for specific ontology
elements.
7. The method of claim 3, further comprising: generating code
representing the ontology in a language specific to a particular
knowledge representation format.
8. The method of claim 7, wherein said generating code includes
generating code that meets DAML+OIL specification.
9. The method of claim 7, wherein said generating code includes
generating code that meets W3C Web Ontology Language (OWL)
specification.
10. The method of claim 7, wherein said generating code includes
generating code that meets Open Knowledge Base Connectivity (OKBC)
specification.
11. The method of claim 3, wherein said accepting as input the
ontology name and the one or more ontology elements includes
validating the ontology name and the one or more ontology
elements.
12. The method of claim 3, wherein said accepting as input the
ontology name and the one or more ontology elements includes
accepting manual input from a user.
13. The method of claim 3, wherein said accepting as input the
ontology name and the one or more ontology elements includes
importing the ontology name and the one or more of the ontology
elements from at least one of an existing knowledge base and
another ontology representation.
Description
[0001] This application is a continuation application of U.S. Ser.
No. 10/499,961 filed on Jun. 21, 2004, which is a U.S. National
Stage Filing under 35 U.S.C. 371 from International Patent
Application No. PCT/US03/04229 filed on Feb. 3, 2003, and published
as WO 2003/069442 on Aug. 21, 2003, which in turn claims the
priority benefit of U.S. Provisional Application Ser. No.
60/356,611 filed on Feb. 12, 2002, the entire content of each
application being incorporated herein by reference.
FIELD OF THE INVENTION
[0002] The present invention relates to knowledge representation
systems. More specifically, the present invention relates to a
method and a system for emulating frame-based knowledge
representation in the unified modeling language ("UML").
BACKGROUND OF THE INVENTION
[0003] Over the last ten years there has been increasing consensus
within the knowledge-based systems community on an appropriate set
of conceptual components for building intelligent systems. These
systems are commonly defined in terms of both domain ontologies and
abstract problem solving methods that operate on the knowledge
bases constructed in terms of those ontologies.
[0004] An ontology is an explicit, formal specification of the
terminology and concepts, as well as the relationships among those
concepts, relevant to a particular domain or area of interest.
Ontologies provide insight into the nature of information
particular to a given field and are essential to any attempts to
arrive at a shared understanding of the relevant concepts. They may
be specified at various levels of complexity and formality
depending on the domain and needs of the participants in a given
conversation.
[0005] Ontology development is important from a collaboration and
software interoperability perspective because every database and
application employs an ontology to model its data, either
implicitly or explicitly. Emerging applications in collaboration,
application integration, web services, and content management
require large, complex ontologies that must be built and maintained
by distributed teams. Despite the increased focus on the creation,
management and use of complex ontologies in intelligent
knowledge-based systems, there is little or no consensus regarding
the requirements for tools to enable the construction of such
knowledge-based systems and the ontologies they use.
[0006] While a significant body of work on frame-based knowledge
representation and ontologies exists in the academic community,
little has been done to foster adoption of these concepts or their
usage in commercial applications. The ontology editors that exist
today are based heavily on research in the Knowledge Interchange
Format ("KIF") and knowledge representation languages descended
from KL-ONE. Most of these tools, including Ontolingua, Chimaera,
Protg, OilEd, and LOOM are little known outside the artificial
intelligence research community. Many of the tools require
significant expertise in the relevant knowledge representation
language and modeling methodology, and in many cases require the
ontologist to have a background in computer programming languages
such as LISP or Prolog. Because these tools have not had the
benefit of commercial investment, most, if not all, are single-user
tools. None are integrated with software engineering or
configuration management tools, and the majority are only supported
as funding permits. Furthermore, none of the tools scale to the
degree required for the construction of large-scale bioinformatics
or other equally complex and sizable ontologies.
[0007] Domain experts with little or no background in knowledge
representation methods need tools that will enable them to develop
knowledge bases and related intelligent systems. The tools must
also provide capabilities for directly importing knowledge not only
from formal knowledge bases but also from reference vocabularies,
other repositories, and relevant applications. The portions of
knowledge bases that are imported from disparate resources then
need to be merged or aligned to one another in order to link the
corresponding terms, to remove redundancies, and to resolve
conflicts. Because such ontologies can be difficult even for
experts to build, the need for a new generation of commercial-grade
tools supporting knowledge sharing and collaborative ontology
development is becoming increasingly urgent.
SUMMARY OF THE INVENTION
[0008] According to one aspect of the invention, there is provided
a method and system for emulating a variety of knowledge
representation systems, including frame based knowledge
representation, in a Unified Modeling Language ("UML") environment.
A Meta-object facility ("MOF") meta-model and UML profile are
grounded in a foundation ontology. Elements of a frame-based
knowledge representation are mapped to elements of the UML
environment based on the MOF meta-model and UML profile, thereby
emulating the frame-based knowledge representation in UML.
[0009] According to another aspect of the invention, a method and
system are provided for creating an ontology in UML. A user input
and validation component accept user-entered input representing an
ontology name and one or more ontology elements. Each user-entered
ontology element corresponds to either a concept or a relationship
between concepts. The user-entered ontology elements form a
detailed specification for the ontology. An ontology logic
component generates a logically equivalent ontology using UML model
elements based on a UML profile. The UML profile is grounded in a
foundation ontology. A UML tool is also provided to present the
logically equivalent ontology to a user in a UML environment.
[0010] According to yet another aspect of the invention, there is
provided a method and system wherein an ontology logic component
generates a UML package and class for each frame type of an
ontology.
[0011] According to still another aspect of the present invention,
there is provided a method and system wherein an ontology logic
component generates a UML association for specific ontology
elements.
[0012] According to yet another aspect of the invention, there is
provided a method and system wherein an ontology logic component
generates a UML operation for specific ontology elements.
[0013] According to still another aspect of the present invention,
there is provided a code generator. The code generator is for
generating code representing an ontology in a language specific to
a particular knowledge representation format.
[0014] According to yet another aspect of the invention, there is
provided a method and system wherein the code generator generates
code that meets the DAML+OIL specification.
[0015] According to still another aspect of the invention, there is
provided a method and system wherein the code generator generates
code that meets the OWL specification.
[0016] According to yet another aspect of the present invention,
there is provided a method and system wherein a code generator
generates code that meets the OKBC specification According to yet
another aspect of the present invention, there is provided a user
input and validation component. The user input and validation
component is to validate an ontology name and one or more
user-entered ontology elements.
[0017] According to yet another aspect of the present invention,
there is provided a user input and validation component, which is
for accepting and to validating manual input from a user.
[0018] According to yet another aspect of the present invention,
there is provided a user input and validation component, which is
for accepting and to validating an ontology name and one or more of
the ontology elements. The ontology name and elements, which are
validated, are accepted from at least one of an existing knowledge
base and another ontology representation.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The present invention is illustrated by way of example and
not intended to be limited by the figures of the accompanying
drawings in which like references indicated similar elements and in
which:
[0020] FIG. 1 illustrates a block diagram of a computer system with
which the present invention may be implemented.
[0021] FIG. 2 illustrates a functional block diagram of the
individual components which make up one exemplary embodiment of the
present invention.
[0022] FIG. 3 illustrates a user perspective diagram showing how
individual actors may interact with one embodiment of the present
invention.
[0023] FIG. 4 illustrates a computer network with which the present
invention may be implemented in one embodiment.
[0024] FIG. 5 illustrates a flow diagram of operations, according
to an exemplary embodiment of the present invention, to emulate
frame based knowledge representation using UML.
[0025] FIG. 6 illustrates a flow diagram of operations, according
to an exemplary embodiment of the present invention, to emulate
frame based knowledge representation using UML.
[0026] FIG. 7 illustrates a detailed functional block diagram of
the individual components which make up one exemplary embodiment of
the present invention.
[0027] FIGS. 8-14 illustrate individual screen shots consistent
with one embodiment of the present invention.
[0028] FIGS. 15-21 illustrate a subset of the inheritance hierarchy
for the foundation ontology according to one embodiment of the
present invention.
[0029] FIGS. 22 through 24 illustrate class diagrams for binary,
ternary, and variable arity relations, according to one embodiment
of the present invention.
[0030] FIGS. 25 and 26 illustrate diagrams for unary and binary
functions, according to one embodiment of the present
invention.
[0031] FIG. 27 illustrates a subset of the inheritance hierarchy
for the foundation ontology defining classes relevant to axiom
expression, according to one embodiment of the present
invention.
[0032] FIGS. 28 through 31 illustrate logical class hierarchies
relevant to the generation of DAML+OIL and OWL ontologies,
including ontology class definitions for RDF Model and Syntax, RDF
Schema, and XML Schema Datatypes, according to one embodiment of
the present invention.
[0033] FIG. 32 illustrates the logical class hierarchy for a
current version of the OWL specification, according to one
embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0034] A method and apparatus for frame-based knowledge
representation in the Unified Modeling Language ("UML") are
described. In the following description, for purposes of
explanation, numerous specific details are set forth in order to
provide a thorough understanding of the present invention. It will
be evident, however, to one skilled in the art that the present
invention may be practiced without these specific details. To
facilitate a full and clear understanding of the present invention,
there is provided a brief description of the concept of ontologies,
including a definition for purposes of the present invention and a
variety of examples.
Ontology
[0035] An ontology typically specifies a description of the
terminology, concepts, and the relationships among those concepts
relevant to a particular domain or area of interest. Ontologies can
provide insight into the nature of information particular to a
given field and are essential to any attempts to arrive at a shared
understanding of the relevant concepts. They may be specified at
various levels of complexity and formality depending on the domain
and needs of the participants in a given conversation (humans,
systems and applications, or intelligent agents, for example):
[0036] A controlled vocabulary may be an ontology that simply lists
a set of terms and their definitions. Glossaries and acronym lists
are two examples of controlled vocabularies. [0037] A taxonomy may
be a set of terms that are arranged into a
generalization-specialization (parent-child) hierarchy. A taxonomy
may or may not define attributes of these terms, and may not
necessarily specify relationships among the terms. XML schemas,
RosettaNet and various XML dialects such as ebXML, ISO/IEC
vocabularies, and STEP standards are examples of taxonomies. [0038]
A relational database schema defines a set of terms through, for
example, classes (tables, where terms are represented as the rows
in those tables), attributes (specified as columns in the tables),
and a limited set of relations between classes (e.g., foreign
keys). Some constraints (such as to define valid values) and
behavioral characteristics (through triggers and stored procedures)
may also be defined for a relational database, though they are not
considered part of the schema, per se. Additional relations may be
specified through applications that access the database, or through
the queries defined on the database, but again, these are not
considered part of the schema itself. [0039] Entity relationship
("E-R") diagrams and data dictionaries are typically used to
document relational database schemas. E-R diagrams can provide a
graphical view of the relevant data elements and their
relationships, but do not describe the constraints, behavior, or
the kinds of relationships that might be expressed in query form.
Data dictionaries may include text definitions for the rows and
columns in a table, limits on field length or other data type
definitions, but again, are not typically used to describe
constraints, behavior, or other relevant relationships. [0040] An
object-oriented software model defines a set of concepts and terms
through a hierarchy of classes, and attributes and a broad set of
binary relationships of those classes. Some constraints and other
behavioral characteristics may be specified through methods on the
classes or objects, and in this case would be considered part of
the ontology. [0041] Standard software engineering methodologies
and best practices relevant to object-oriented systems development
include requirements and configuration management, use case
modeling, architectural analysis and design, object-oriented
analysis and design, implementation, test, and deployment
management. Documentation developed over the course of a project
implementing these best practices includes use-case models and
realization diagrams, analysis models, collaboration and
interaction diagrams, architecture and design models, sequence
diagrams, implementation (state transition diagrams, class diagrams
and models, etc.) and deployment models, etc. These models and
related software engineering documentation typically include all of
the information present in data dictionaries and E-R diagrams, as
well as rich information about the relevant relationships (both
hierarchical and lateral) and behaviors defined for a system.
[0042] A knowledge-representation system may be based on
first-order logic and can express all of the preceding
relationships, as well as n-ary relations, a rich set of
constraints, rules relevant to usage, and other differentiators
including negation and disjunction. Such a system may specify an
ontology as a catalog of the terms used in a domain, the rules
governing how those terms can be combined to make valid statements
about situations in that domain, and in some cases, the sanctioned
inferences that can be made when such statements are used in that
domain. The system may also characterize the behavior of objects
and associations in the domain. Thus, an ontology might be
described as a data dictionary, plus a grammar, plus a model of the
behavior of a domain. [0043] The concepts or terms relevant to a
particular domain ontology can be defined recursively, to
increasing levels of granularity. The building blocks (classes,
relations, functions, and individuals) of an ontology may be
specified so that they are reusable across distinct definitions.
Rich relations among these terms can be defined at all levels in
what is called a semantic network. The combination of these rich
definitions, the relationships among them, and the rules that
specify constraints on their usage or additional relevant behavior
enable unambiguous differentiation among concepts and resolution of
language or terminology conflicts across multiple repositories and
applications.
[0044] Ontology development is important from a collaboration and
software interoperability perspective because every database and
application employs an ontology, either implicitly or explicitly,
to model its data. The more fine-grained the ontology, the more
precisely a knowledge base will be able to model the nuances of the
data that it tries to capture. A coarse-grained ontology will model
only superficial aspects of the data, and therefore may not capture
concepts or relations that are important for some problem-solving
task. A semantically malformed ontology is one that incorrectly
models the semantics of its application domain, and therefore
yields a knowledge base whose structure corrupts or restricts the
information that it is intended to hold.
[0045] Ontologies developed in true knowledge representation
systems capture and represent finely granulated knowledge in an
unambiguous way so that this information can be shared and acted on
by diverse groups of people and systems linked together by a
network. Concepts and resources can be described in multiple ways,
depending on point of view, cultural background, or role of the
individual describing them. A single concept (or description of a
concept) may apply to multiple contexts or situations, but the
meaning associated with that concept may be sensitive to the
context or situation. Conceptual knowledge is rarely strictly
hierarchical in nature. A lattice, network, or group of networks
provides a richer, more complete, and more accurate representation
of complex interrelated concepts and terminology.
Component-Based Ontology Development
[0046] Best practices in software engineering mandate
well-designed, component-based software architectures for sharing
information in a networked environment that are specified in terms
of layers of functionality, such as separate Delivery,
Presentation, Process and Integration, Business or Application
logic, Content and Data Management, and Infrastructure layers. The
capabilities provided within each layer are encapsulated to support
highly distributed systems, load balancing, and so forth (as in an
n-tiered architecture). In the same manner, ontologies can be
described in terms of the different aspects of an architecture they
address for attempting to solve different kinds of collaboration or
integration problems.
[0047] A domain ontology, which may also be call a classic
ontology, may define the terminology and concepts relevant to a
particular topic or area of interest.
[0048] A process ontology may define the inputs, outputs,
constraints, relations, terms, and sequencing information relevant
to a particular business process or set of processes, for example,
through concepts such as those utilized by process modeling tools
built on EXPRESS, the Process Specification Language ("PSL"), or
the Business Process Modeling Language ("BPML").
[0049] An interface ontology may define the structure and content
restrictions (such as reserved words, units of measure
requirements, other format-related restrictions) relevant for a
particular interface (e.g., application programming interface
("API"), database, scripting language, content type (such as for a
wireless server), user view or partial view--as implemented for a
portal, for instance), using concepts such as those employed by
Object Management Group's Model Driven Architecture ("MDA") and
related specifications.
[0050] A service ontology may define the vocabulary, tasks, and
related parametrics for a given service, or set of services, such
as a Common Object Request Broker Architecture ("CORBA") service or
web service (e.g., through Darpa Agent Markup Language for Services
("DAML-S"), UML Action Semantics, Web Service Description Language
("WSDL")).
[0051] A role ontology may define terminology and concepts relevant
for a particular end-user (agent, person, application, or
resource).
[0052] Such a systematic, component-based approach to ontology
modeling is helpful to the success of large-scale ontology
construction projects. Those skilled in the art of software
engineering have demonstrated that building a single, monolithic
enterprise data model is costly and fails to deliver the desired
utility. Ontologies are, by nature, much larger and more complex
than data models, and can require significant effort to build. Just
as an artist might apply color to a serigraph in layers, ontologies
may be developed from a variety of perspectives and layered on top
of one another until a complete picture emerges. For example, by
isolating an interface ontology from the terminology relevant for a
domain, it may be possible to limit the changes required when an
obsolete application is updated or replaced with new functionality
to the interface ontology. Cross-organizational communications
mismatches can be minimized, if not eliminated, by creating
ontologies that reflect the terminology, jargon, nomenclature, and
domain applications specific to one community, mapping the
ontologies to those of another community with differing cultural
heritage, and brokering over the conceptual knowledge exemplified
in the ontologies and mappings. Brokering across multiple interface
ontologies reflecting various metadata standards, XML dialects, and
database access methodologies can enable broad accessibility while
limiting breakage when any particular interface is changed. One
embodiment of the present invention facilitates component-based
ontology development, and incorporates mechanisms to support this
methodology as described below.
[0053] In one embodiment of the invention, during an ontology
creation process, an ontologist identifies which kind of ontology
component they are constructing (e.g. domain, process, interface,
service, or role). A sixth ontology kind, called upper, may be
reserved for high-level conceptual knowledge, such as whether a
particular concept is abstract or concrete, animate or inanimate,
and so forth. In one embodiment, the ontology kind is preserved
with the ontology as a property of the model, as discussed below.
It may also be used to determine lineage and form of the ontology.
The system may suggest, for example, that a process ontology should
be a child of Process (or of some specialization of Process) and be
based on the Process Specification Language ("PSL") ontology
provided as a guideline for process ontology development, or that a
service ontology should be a child of Service (or of some
specialization of Service) and be based on the service ontology
(DAML-S and UML Action Semantics based).
[0054] In addition to the use of this ontology kind property and
optional use of an appropriate reference ontology as a basis for
development, every ontology may be created as a controlled unit
from a configuration management perspective. A separate container
is created within a UML tool environment and in the file system for
that ontology. Each first class model element (ontology, class,
relation, function, or individual) is maintained as a separate
controlled unit in one embodiment of the invention as well. This
approach allows multiple users to work on the same ontology and
maintain separate version and revision control of individual
components of the ontology through integration with a software
configuration management system.
EXEMPLARY EMBODIMENT OF THE INVENTION
[0055] In an exemplary embodiment, a computer system, such as that
illustrated in FIG. 1, is used to implement the invention. FIG. 1
illustrates the computer system 100 as including a processor 150
operatively connected to a random access memory ("RAM") 150 and a
read only memory ("ROM") 140 by a system bus 110. Processor 130 is
also operatively connected to a fixed disk 190, which may be an
optical disk or other storage medium, through input/output bus 120.
Alternatively, processor 130 may be connected to multiple storage
devices through input/output bus 120. Processor 130 communicates
data using system bus 110 and input/output bus 120.
[0056] System bus 110 and input/output bus 120 may also receive
inputs from keypad 195, or input device 170. System bus 110 and
input/output bus 120 may provide outputs to display 160, output
device 180, or fixed disk 190. Memory and storage media 140, 150
may also include a flash memory, EEPROM, or any combination of the
above.
[0057] Computer system 100 may be controlled by operating system
software, which includes a file management system, such as a disk
operating system, which is part of the operating system software.
The file management system may be stored in a non-volatile storage
device, such as RAM 150, and may be configured to cause processor
140 to execute various functions required by the operating system
to input and output data and to store data in RAM 150 or ROM
140.
[0058] For one embodiment, the present invention is implemented as
a set of instructions stored on exemplary computer system 100 and
executed by processor 130. However, one skilled in the art will
realize that the present invention is independent of the components
of computer system 100 or the particular operating system executing
on computer system 100. In particular, the present invention may be
implemented in either a UNIX or Windows based computer system.
[0059] FIG. 2 illustrates a functional block diagram of an
exemplary embodiment of the present invention as an integrated
add-in component for Rational Software's.RTM.. Rose Enterprise
Edition.RTM., an existing UML tool 200. The add-in component
provides several advantages when implemented as an add-in to an
existing UML environment or tool. The Unified Modeling Language is
a graphical language for visualizing, specifying, constructing, and
documenting the artifacts of distributed object systems. UML has
been widely adopted by commercial software engineering
organizations for use in the development of object-oriented
applications. Its lineage stems from object-oriented analysis and
design methods for modeling software components that converged in
the mid 1990's. Further evolution led to the formation of an
independent standards body within the Object Management Group that
formalized and integrated UML with other standardization efforts in
the late 1990's and adopted UML 1.1 as a standard in 1997.
[0060] In one embodiment, the present invention may be based on the
most recently adopted specification for UML, namely UML 1.4
including the Meta-Object Facility ("MOF") version 1.4 and the XML
Metadata Interchange version 1.1. While the invention has been
implemented to work with and take advantage of current
specifications and standards, one skilled in the art will recognize
that alternative embodiments of the invention can be implemented to
evolve with the UML family of standards as they themselves
evolve.
[0061] Because UML enjoys a rapidly growing user community and has
gained wide acceptance amongst commercial developers as a tool for
object-oriented analysis, design, and implementation, implementing
the component as an add-in to existing UML tools provides some
advantages. Most UML development tools are multi-user and many are
integrated with commercial-quality configuration management
capabilities. Some also provide facilities for round-trip
engineering of various information and software resources that
might be of interest as sources for ontology development.
Furthermore, as an add-in to existing UML tools, the component
enables graphical, collaborative, component-based ontology
development. In conjunction with a UML tool having the appropriate
API and display capabilities, an add-in according to one embodiment
of the present invention can facilitate ontology import, analysis,
alignment, manipulation, merge, and export/generation. Still
further advantages include support for various methods of
classification, consistency and integrity checking, transitive
closure, and other model verification capabilities.
[0062] It will however be appreciated that the invention is not
limited to an add-in component, and could operate as a standalone
application that integrates with a further application or could be
completely integrated with another application, for example.
[0063] Referring once again to FIG. 2, the exemplary add-in
component consists primarily of sub-components, including: a visual
ontology modeler 205, a UML ontology library 210, a visual ontology
modeler expression editor and code generator 215, an ontology and
instance data knowledge base 220 and language specific documents
225. The add-in component will be described in further detail with
respect to FIG. 7 below.
[0064] FIGS. 3 and 4 are diagrams illustrating some of the
networking and multi-user aspects of one embodiment of the
invention. FIG. 3 illustrates how various actors interact with
different aspects of an embodiment of the invention. In FIG. 3,
each actor 305, 310, 315, and 320 is shown to interact in a variety
of different ways by performing functions specific to his role. For
example, a knowledge engineer 305 interacts with one embodiment of
the invention by performing several functions including: reverse
engineering a resource 325, importing an ontology 330, creating an
ontology 335, analyzing and maintaining an ontology 340, and
generating a knowledge base or instance data repository 345. A
knowledge base and code generator actor 315, has more limited
interaction. Actor 315 is shown to interact by performing functions
such as generating a knowledge base 345 and exporting an ontology
350. For one embodiment of the invention, the particular UML tool
200 limits each actor's functionality based on the actor's role.
For example, in one embodiment, a domain expert 320 can maintain a
knowledge base 355, export an ontology 350, and analyze and
maintain an ontology 340, but is restricted from creating a new
ontology 335.
[0065] In one embodiment, the present invention is implemented to
work over a network of computers, as illustrated in FIG. 4. FIG. 4
includes personal computer 415, a laptop computer 410, and an
exemplary workstation 100 interconnected via network 405. Network
405 may be a local area network, such as an office intranet, or a
wide area network, such as the Internet. In one embodiment, the
invention is implemented as add-in components 205, 210, 215, 220
and 225 for a UML tool 200 on workstation 100. A knowledge engineer
305, using workstation 100, can perform an import ontology
operation 330, to import an existing ontology that resides on
personal computer 415. Similarly, an ontologist 310, using
workstation 100, can perform an export ontology operation 350 to
export an ontology to laptop computer 410.
[0066] FIG. 5 illustrates a flow diagram of operations 500,
according to an exemplary embodiment of the present invention, to
emulate frame based knowledge representation using UML. The method
begins at operation 505. At operation 505, there exists an ontology
represented as a group of elements specific to a particular
knowledge representation system. For example, at operation 505 an
ontology might be represented with elements common to knowledge
representation systems including but not limited to the Knowledge
Interchange Format, Ontolingua, Open Knowledge Base Connectivity,
or Protege. At operation 510, the elements, represented in one of
the above knowledge representation systems, are mapped to UML
elements based on the Meta-Object Facility ("MOF") meta-model and
UML profile 15. The MOF meta-model and UML profile are illustrated
in greater detail in Table 1 below. At operation 520 the original
ontology is emulated in UML by UML elements. As such, the ontology
can be manipulated and acted upon like any other UML model.
TABLE-US-00001 TABLE 1 Core Profile for Frame-based Knowledge
Representation Frame-Based Frame-Based KR MOF UML (Ontology)
Metamodel Metamodel Element Element(s) Element(s) Stereotype
Ontology Package Package ontology Class Package Package classFrame
(frame) Class Class ontologyClass Relation Package Package
relationFrame (frame) Class Class relation Function Package Package
functionFrame (frame) Class Class function Association Association
hasFunction Operation Operation function Individual Package Package
individualFrame (frame) Class Class individual Association
Association individualOf, typeOf Slot Package Package slotFrame
Class Class slotRelation Association Association hasOwnSlot,
hasTemplateSlot Facet Association Association valueType, hasValue,
hasDefaultValue Attribute Attribute facet Axiom Class Class axiom
Association Association (depends on the axiom) Operation Operation,
axiom External File
[0067] The flow diagram of FIG. 6 illustrates operations 600 to
create an ontology using UML, according to one embodiment of the
present invention. The method begins at operation 605. At operation
605 user-entered input representing the elements of an ontology for
a knowledge representation system are accepted. At operation 615,
UML elements are generated. The UML elements are generated based on
a UML profile, such as that illustrated in Table 1, and are
logically equivalent to the elements for an ontology represented by
many other knowledge representation systems. At operation 620 the
resulting UML ontology is model is presented to a user. Operation
625 is the end.
[0068] FIG. 7 illustrates a functional block diagram of an
exemplary embodiment of the invention implemented as an integrated
add-in component for an existing UML tool. For example, as
illustrated in FIG. 2, the invention can be implemented as an
add-in component for Rational Software's.RTM.. Rose Enterprise
Edition.RTM., a UML modeling environment. In other embodiments, the
present invention may be implemented as an add-in for a variety of
other UML tools and environments, including: Rational.RTM..
Software's extended Development Experience and Borland's
TogetherSoft.TM.. UML modeling tool. As discussed above, the
invention may be implemented as an integrated add-in to existing
UML tools because the invention can leverage the powerful features
of existing UML tools when implemented as an integrated add-in
component to such tools. However, in alternative embodiments, the
invention can be implemented as a stand-alone tool.
[0069] Further details regarding an exemplary add-in component 700
are shown in FIG. 7. Specifically, the add-in component 700 of FIG.
7 includes a visual ontology modeler component 705, a UML ontology
library 710, an expression editor 715 and a code generator 720.
Visual ontology modeler 705 is a core component and tightly
integrates with UML tool 765. Visual ontology modeler 705 has
several sub-components, which provide much of the functionality.
Visual ontology modeler 705 includes a user interface and
validation component 725, a file system interface component 730, a
utility component 740, a knowledge representation specific utility
component 745, and an ontology logic component 735.
[0070] For one embodiment, user interface and validation component
725 provides much of the logic and support for interfacing with the
user. For example, user interface component 725 in conjunction with
UML tool 765 facilitates the presentation of input text boxes and
wizard interface components to the end user for receiving user
input. User interface component 725 receives input from the user
and performs validation routines on the input to verify that the
input meets certain specified criterion. For example, in one
embodiment of the invention there are naming conventions for
ontologies and the frames that represent ontology elements. The
validation component verifies that user-entered names conform to
such naming conventions.
[0071] Ontology logic 735 serves several key functions. For one
embodiment of the invention, ontology logic 735 receives
user-entered input from user interface component 725 and creates
the UML model elements corresponding to the user-entered input. For
example, when an ontology is created, user interface 725 will
present the user with a text box in which the user must enter a
frame name, and a code name for the ontology. Once entered,
ontology logic 735 creates the UML model elements necessary to
emulate the corresponding ontology. Specifically, ontology logic
735 creates a new model with a name and identification
corresponding to the naming details provided by the user interface
component 725 in the UML tool, and a UML package, again with
identification details provided by the user interface component
725, within that model to emulate a frame representing an ontology.
Ontology logic 735 may also create empty packages under the
ontology package to emulate the various frames of the ontology,
including packages for classes, relations, functions, and
individuals. Finally, ontology logic 735 may populate UML model
properties of the ontology model corresponding to the identifying,
administrative, and other information solicited from the user as
described in further detail, below.
[0072] Ontology logic 735 also performs many functions specific to
the UML tool 765. In one embodiment, ontology logic 735 may create
UML tool specific files. For example, when implemented as an add-in
for Rational Rose.TM., ontology logic 735 may use the Rose API to
interact with the Rose environment to create the requisite model
elements and related files, including what are called petal files
and cat files for the model. Ontology logic 735 may request the
file system interface component 730 to create a folder in the
Ontology Library 710 corresponding to the model created in the UML
tool 765, and to create empty folders corresponding to the empty
packages to contain the various frames of the ontology. The petal
and .cat files for the model may be saved in the model folder in
the Ontology Library. An XML file detailing model properties may
also created in the ontology folder.
[0073] For one embodiment of the invention, file system interface
component 730 reads and writes model elements to a file storage
device, such as fixed disk 190. In an alternative embodiment, file
system interface component 730 may be implemented to interface with
a commercial database. For example, file system interface component
730 may read from and write to a standard commercial database
containing a knowledge base or instance database.
[0074] Utility component 740 performs a variety of functions. For
one embodiment, utility component 740 performs operations
including: opening existing ontologies, creating overview diagrams
of UML models, and browsing frame and slot elements. Utility
component 740 may also be implemented to perform file system
clean-up routines and model checking and verification routines.
[0075] Knowledge representation language specific utility component
745 performs routines that are specific to a particular knowledge
representation language. For example, for one embodiment of the
invention, language specific utility component 745 performs
operations to create "relation" ontology elements that are specific
to such knowledge representation systems as DAML+OIL, OWL, or KIF.
A table containing examples of relations specific to DAML+OIL and
OWL is provided below in Table 9.
[0076] UML ontology library includes language specific ontologies
750, MOF meta-model 755 and foundation ontology 760. In one
embodiment of the invention, the MOF meta-model 755 is an integral
part of the foundation ontology 760, as shown in Figures ? through
?. For one embodiment of the invention, MOF meta-model 755 and the
foundation ontology 760 may facilitate user import of other
foundation, or upper ontologies of choice, such as the IEEE SUO or
SUMO ontologies. The MOF meta-model 755 and the foundation ontology
760 facilitate code generation for specific knowledge
representation systems and ontology languages. However, one skilled
in the art will recognize that the foundation ontology 760 cannot
support every knowledge representation language.
[0077] Therefore, in one embodiment of the invention, support for
ontologies represented in the Knowledge Interchange Format,
DAML+OIL, and OWL are embedded in the foundation ontology. In
alternative embodiments, language-specific ontologies 750 provide
support for ontologes represented in other knowledge representation
systems, such as the Knowledge Interchange Format and ontologies
representing concepts for XML Schema Datatypes, RDF Model and
Syntax, and RDF Schema (Resource Description Framework), all of
which are specifications of the W3C.
[0078] Add-in component 700 of FIG. 7 also includes expression
editor 715, and code generator 720. In one embodiment, expression
editor 715 facilitates the entering of text for axiom expressions.
In another embodiment of the present invention, code generator 720
provides a mechanism for generating code for other knowledge
representation systems. Code generation is described in greater
detail below.
Frames
[0079] In many knowledge representation systems, the primary
ontology elements utilized include ontology, class, relation,
function, individual, slot, facet and axiom. In one embodiment of
the present invention, as in most frame-based knowledge
representation systems in general, several of the primary ontology
elements listed above are represented as frames. For example, Table
1 shows the class, relation, function, and individual ontology
elements associated with frames. A frame in the context of the
present invention is a conceptual container for meta-knowledge
defining a given entity in the domain of discourse. In one
embodiment of the present invention, two UML constructs are
employed as stereotypes for frame representation: UML packages,
which allow clustering multiple definitions of various types in the
same component, and UML classes, which support relations among
frames and enable association of behavior (or methods) with frames.
In addition, one embodiment of the present invention employs UML
associations to represent specific relations among frames,
including relating slots and facets to frames.
[0080] On creation of any frame, in one embodiment of the
invention, several model elements are created, including certain
naming and identifying characteristics. These include: frame name,
frame identifier, frame code name, and frame documentation. For
example, when an ontology ontology element is created, UML model
elements are generated to capture values for the frame name, frame
identifier, frame code name, and frame documentation associated
with the created ontology. UML model elements for naming and
identification are generated for all first class ontology elements
represented by frames, including the class, relation, function, and
individual ontology elements.
[0081] Consistent with the invention, the frame name is defined as
the name associated with a given frame. This name is assigned to
the UML model elements that implement the frame. For example, from
Table 1 it can be seen that the function ontology element is
represented by a frame. The name for that frame is assigned to the
operation UML model element that emulates that particular
frame.
[0082] The frame name for an ontology element must be unique across
all ontologies. For example, no ontology can have the same name.
Furthermore, frame names for ontology elements within a given
ontology must be unique. However, frame names for ontology elements
other than ontology need not be unique across ontologies. For
example, there may be terms relevant to distinct domains or
resources that have the same name but may or may not have identical
definitions. Note that frame names are called pretty names or
display names in some knowledge representation systems, and are the
names used in documentation, to provide visual identification for a
particular element in graphical views, and so forth.
[0083] In one embodiment of the invention, the following naming
convention are used with respect to frame names: [0084] Every frame
name must begin with an alpha character (A-Z, a-z). [0085] Every
unique word within the frame name should also have an initial
uppercase alphanumeric character or preceding space or underscore
to identify word boundaries (e.g., minimum cardinality or
minimumCardinality). [0086] Frame names are restricted to
combinations of upper and lower case alphanumeric (ASCII)
characters, numbers (0-9), spaces, underscores, and dashes;
punctuation characters and other special characters are
disallowed.
[0087] A frame identifier is a unique, machine-generated identifier
assigned to a given frame. Again, in cases where applicable, unique
identifiers are assigned to the UML package and/or UML class that
implement the frame. These identifiers are, by definition, unique
both within and across ontologies, so that distinctions among terms
that have the same name but different definitions can be
maintained.
[0088] A frame code name is defined as the internal name associated
with a given frame for a knowledge base, XML, and other code
generation purposes. Again, this name is assigned to any UML
element that implements the frame, and is not required to be unique
across ontologies. It must be unique within an ontology, however.
In addition to the restrictions given above for frame names, code
names cannot contain spaces, underscores, or dashes.
[0089] Frame documentation refers to optional text information
associated with a given frame, either on creation or during the
development process. Frame documentation is a free form text field
that must be non-blank on release of a given version of an
ontology. The default value for frame documentation provided at
frame creation is Documentation not yet supplied.
[0090] FIGS. 8-14 illustrate screen displays that are presented to
the user when creating an ontology for one embodiment of the
invention.
Ontology Frames
[0091] An ontology frame is a frame that acts as a container for
all of the entities (documentation, inclusion relationships with
other ontologies, and local class, relation, function, individual,
slot, facet, and axiom frames) defined for a particular ontology.
In order to fully encapsulate component ontologies for reuse and
collaborative development purposes, ontology frames are implemented
as UML packages. Every ontology frame has a frame name, frame
identifier, and frame code name associated with it as stated above.
Ontology frame code names are used not only for identification
purposes in the present invention, but for namespace identification
as well. For example, when generating DAML+OIL or OWL code for a
particular ontology the frame code name is used as namespace
identification.
[0092] Additionally, terms specifying details used for ontology
alignment, brokering, maintenance, configuration management, code
generation or simply to provide additional descriptive information
are requested from the ontologist. They are maintained as UML
properties on the model implementing the ontology, and, include:
[0093] Abstract [0094] Ontology Kind [0095] Creation Date [0096]
Revision Date [0097] Version [0098] Revision [0099] Originator
[0100] Point of Contact [0101] References [0102] Keywords [0103]
Deployment URI
[0104] An abstract is a brief narrative description providing
sufficient information about the ontology to identify its general
nature, the original purpose for its development, and other summary
documentation that might be relevant for collaborative or reuse
purposes (required). This information is implemented as the frame
documentation in one embodiment of the invention.
[0105] The ontology kind term is used to assist the user in
selecting a parent class for the ontology (e.g., Process, for a
process ontology, or Entity (Thing) for a domain ontology), and in
certain cases, to select an existing ontology as a metamodel or to
provide a meta-vocabulary to ground the ontology under development
(such as the Process Specification Language ontology) for code
generation purposes. This term is required.
[0106] A creation date is automatically generated when an ontology
is first created. This term is required and cannot be manually
modified. Similarly, the revision date is automatically updated
each time the ontology frame or any of the entities that compose a
given ontology are changed, and cannot be manually modified.
[0107] The version and revision terms are optional. The terms
version and revision are used for configuration management
purposes, where a given version of an ontology may have multiple
minor revisions associated with it. Consistent with the present
invention, ontology development can be a collaborative and
iterative process potentially involving teams of people.
Consequently, there exists a need to manage multiple versions of
component ontologies throughout the development lifecycle. The
present invention may be implemented by formally integrating an
add-in component with configuration management functionality, such
as Rational Software's.RTM. ClearCase.RTM., for example. In such an
embodiment fields specific to the configuration management tool
would replace the above fields with equivalent information
generated and managed by the control system.
[0108] The originator term refers to the organization that created
and maintains the ontology. In a large organization, originator
should include the departmental reference and primary address,
telephone, facsimile and email information as well as information
concerning how that department fits in to the larger organization
(such as an organizational chart). For one embodiment, this term is
considered optional, however in a preferred embodiment it is used
for all collaborative ontology development projects.
[0109] The point of contact term refers to the individual or
individuals who are responsible for ongoing maintenance of the
ontology, and should include their organization, address,
telephone, facsimile and email information at a minimum. Again, in
one embodiment this term is considered optional, but in a preferred
embodiment it is used for all collaborative ontology development
projects.
[0110] The references term is a brief narrative description
providing information regarding the reference materials used in the
development of a given ontology, including any controlled
vocabularies, taxonomies, international or national standards,
systems specifications and data dictionaries (in the case of an
ontology describing a particular resource), cross references,
methodology documents or other relevant supplemental information.
In addition to the narrative, for each individual reference, the
title, author, date of publication, publisher information and a
current link to the document (if available) should be provided.
Additional documentation terms may be added to suit corporate or
other standards as needed.
[0111] The keywords and deployment URI terms provide descriptive
information regarding the utility or domain of interest and
ultimate Internet deployment location of the ontology (if
applicable), respectively, and are used primarily for code
generation in one embodiment of the invention.
Own Slots and Own Facets
[0112] Slots represent the characteristics (attributes or
properties in other modeling paradigms) associated with a
particular frame (ontology class, relation, function, or
individual), while facets represent the characteristics associated
with particular slots on a given frame. Slots can be used to
specify or constrain the values or behavior associated with a
frame. Similarly, facets may be used to specify or constrain the
values or behavior associated with a particular slot on a
frame.
[0113] In one embodiment of the present invention, slots are
related to frames through the slotRelation stereotype, where the
slots themselves must be defined as classes, relations, or
functions, either in the same or another ontology. Facets represent
constraints on particular slots, and may be implemented in various
ways depending on the facet definition. Facet implementation
exploits native UML constructs where appropriate, such as in the
case of cardinality. Facets may be related to slots through UML
attribute definitions, or where required, as ternary relations
between individual slots on particular frames and previously
defined entities.
[0114] According to one embodiment, first class ontology frames
(e.g., class, relation, function and individual frames) have own
slots associated with them, which describe characteristics of the
frames themselves or constrain them in some fashion. Each own slot
has a set of slot values associated with it. Conceptually, a slot
is a binary relation, and each value V of an own slot S of a frame
F represents the assertion that the relation S holds for the entity
represented by F and the entity represented by V (i.e., (S F V)).
For example, the assertion that Benson's hobbies are swing dancing
and assembling personal computers could be represented by the slot
hasHobbies of the frame Benson having as values the frame
swingDancing and the string `assembling PCs`.
[0115] Each own slot has a set of own facets associated with it,
and each own facet has a set of facet values associated with it.
Conceptually, a facet is a ternary relation, and each value V of
own facet Fa of slot S of frame Fr represents the assertion that
the relation Fa holds for the relation S, the entity represented by
Fr, and the entity represented by V (i.e., (Fa S Fr V)). For
example, the assertion that Benson must have at least one hobby
could be represented by the facet minimumCardinality of the slot
hasHobbies of the frame Benson having the value 1.
[0116] A number of relations and functions are made available by
default for use by ontologists in various knowledge representation
systems. A subset of these are considered necessary for compliance
with the Open Knowledge Base Connectivity, for example. In one
embodiment of the invention, a baseline set of default slots and
facets representing a number of common constraints or other
relations relevant to ontology modeling in UML have been
implemented. This set is not exhaustive, but is sufficient to
enable code generation out of the modeling environment for
consumption by applications that are OKBC compliant, or for
DAML+OIL or OWL ontologies, for example.
[0117] Table 2 provides a list of own slots that comprise the
default own slots implemented in one embodiment of the invention
for all frame types (classes, functions, relations, and
individuals) with their mapping to MOF and UML and related
type.
TABLE-US-00002 TABLE 2 Default Own Slots for All Frame Types. MOF
& UML Metamodel Slot Value Slot Name Element Stereotype Type
Multiplicity Initial Value Alias Association alias same as the *
frame type Arity Association integer 1 1 for classes and
individuals, relation arity for relations and functions Complement
Association complement same as the * frame type Documentation
Association documentation string 1 Documentation property Frame
Code Name Property string 1 Code Name property Frame Identifier
Property string 1 Rose UID Frame Name Property string 1 Name
property Has Own Slot Association hasOwnSlot slotRelation * Has
Template Slot Association hasTemplateSlot slotRelation *
Classes and Individuals
[0118] In one embodiment of the present invention, a class defines
a set of entities. Each of the entities defined by the class are
called instances of the class, or individuals. A class frame is a
frame that acts as a container for the entities that specify a
particular ontology class. In order to encapsulate the range of
entities associated with a particular ontology class, including its
slots and facets, ontology classes are implemented as a combination
of a UML package and a corresponding UML class, which are
identified by the same frame and code name in one embodiment. Class
frames may also include documentation and the set of slot relations
associated with the class.
[0119] An individual is an instance of a class, which is called its
type. The specification for an individual includes the frame name,
identifier, code name and documentation, as well as the inherited
slots and related values specified for that instance. Individuals
are represented as UML classes (with a stereotype of individual) so
that they may be referenced as slot values, facet values, or as
entities in relations or functions, and in order to encapsulate any
relevant axioms with the individual. Constants are represented by
individuals, for example.
[0120] A class can be an instance of a class. A class that has
instances that are themselves classes is called a meta-class.
Following object-oriented software engineering standards,
meta-classes may not have instances that are individuals. A
relation can be an instance of another relation (i.e., of a
meta-relation, such as a generic binary relation) and a function
can be an instance of a relation or another function. Individuals,
on the other hand, must be instances of classes (i.e., they cannot
be instances of relations, functions, other individuals, or axioms
in the present invention, unlike some other knowledge
representation systems).
[0121] The unary relation class is true if and only if its argument
is a class. The class membership relation (called individualOf)
that holds between an individual and a class is a binary relation
that maps entities to classes. A class is considered to be a unary
relation that is true for every instance of the class. That is,
[0122] (<=>(holds ?C ?I) (individualOf ?I ?C))
The relation typeOf is defined as the inverse of the relation
individualOf. That is,
[0123] (<=>(typeOf ?C ?I) (individualOf ?I ?C))
The subclassOf relation can also be defined in terms of the
individualOf relation, as follows. A class Csub is a subclass of a
class Csuper if and only if all instances of Csub are also
instances of Csuper. That is,
TABLE-US-00003 (<=>(subclassOf ?Csub ?Csuper) (forAll ?I
(=> (individualOf ?I ?Csub) (individualOf ?I ?Csuper))))
The relation superclassOf is defined as the inverse of subclassOf.
That is,
[0124] (<=>(superclassOf ?Csuper ?Csub) (subclassOf ?Csub
?Csuper)) [0125] These and a number of other key relations are
implemented as relations (or functions, where appropriate) in the
fundamental ontology that underlies the present invention (see
Fundamental Ontology for additional detail). Table 3 provides a
list of the additional default own slots implemented in one
embodiment of the invention for all class frames with their mapping
to MOF and UML and related type.
TABLE-US-00004 [0125] TABLE 3 Default Own Slots for Classes. MOF
& UML Metamodel Slot Value Multi- Initial Slot Name Element
Stereotype Type plicity Value All Instances Association boolean 1
false Disjoint Association set of * Decomposition classes Domain Of
Association domainOf class * Exhaustive Association set of *
Decomposition classes Range Of Association rangeOf function *
Subclass Of Specialization class * Superclass Of Generalization
class * Type Of Association typeOf individual *
Ontology Class Frames, Template Slots, and Template Facets
[0126] An ontology class frame may have a collection of template
slots associated with it that define slots considered to hold for
each instance of the class represented by the frame. The values of
template slots are said to inherit to the subclasses and to the
instances of a class (individuals). Each value V of a template slot
S of a class frame C represents the assertion that the relation
hasValue holds for the relation S, the class represented by C, and
the entity represented by V (i.e., (hasValue S C V)). This
assertion implies that the relation S holds between each instance I
of class C and value V (i.e., (S I V)). It also implies that the
relation hasValue holds for the relation S, each subclass Csub of
class C, and the entity represented by V (i.e., (hasValue S Csub
V)). That is, the following slot value inheritance axiom holds for
the relation hasValue:
TABLE-US-00005 (=> (hasValue ?S ?C ?V) (and (=> (individualOf
?I ?C) (holds (?S ?I ?V)) (=> (subclassOf ?Csub ?C)(hasValue ?S
?Csub ?V))))
[0127] In other words, according to one embodiment of the
invention, the values of a template slot are inherited to the
subclasses as values of the same template slot and to instances as
values of the corresponding own slot.
[0128] A template slot of an ontology class frame may have a
collection of template facets associated with it that describe own
facet values considered to hold for the corresponding own slot of
each instance of the class represented by the class frame. As with
the values of template slots, the values of template facets inherit
to the subclasses and instances of a class. Template facet
implementation varies, depending on the nature of the facet; again,
some facets are implemented as UML attributes, others as relations.
In cases where facets are implemented as relations, each value V of
a template facet F of a template slot S of a class frame C
represents the assertion that the relation hasValue holds for the
relations F and S, the class represented by C and the entity
represented by V (i.e., (hasValue F S C V)). This assertion implies
that the relation F holds for the relation S, each instance I of
class C, and value V (i.e., (F S I V)). It also implies that the
relation hasValue holds for the relations S and F, each subclass
Csub of class C, and the entity represented by V (i.e., (hasValue F
S Csub V)).
[0129] In general, the following facet value inheritance axiom
holds for the relation hasValue:
TABLE-US-00006 (=> hasValue ?F ?S ?C ?V) (and (=>
(individualOf ?I ?C) (holds ?F ?S ?I ?V)) (=> (subclassOf ?Csub
?C)(has ?F ?S ?Csub ?V))))
[0130] In other words, the values of a template facet are inherited
to the subclasses as values of the same template facet and to
instances as values of the corresponding own facet. Note that
template slot values and template facet values necessarily inherit
from a class to its subclasses and instances.
[0131] Table 4 provides a list of default facets implemented in one
embodiment of the invention for applicable slot relations with
their mapping to MOF and UML and related type. Note that this list
is not considered exhaustive and is subject to change, as are the
lists of slots provided in Table 2, Table 3, and Table 5.
TABLE-US-00007 TABLE 4 Default Facets. MOF & UML Metamodel
Facet Value Initial Facet Name Element Stereotype Type Value All
Values* Association allValues set Cardinality Attribute nonnegative
integer Collection Attribute enumerated Type list: (none, bag,
list, set) Defining Attribute Boolean false Characteristic
Documentation Association documentation string Essential Attribute
Boolean false Characteristic Has Default Association
hasDefaultValue individual Value Has Value Association hasValue
individual Maximum Attribute nonnegative Cardinality integer
Minimum Attribute nonnegative Cardinality integer Nonessential
Attribute boolean false Characteristic Numeric Attribute integer
Maximum Numeric Attribute integer Minimum *All Values provides a
means to specify a list of possible values, such as an enumerated
list, for the facet, which also restricts the slot to only those
values.
Relation and Function Frames
[0132] According to one embodiment of the invention, a relation
defines the relationship among a collection of entities. A relation
frame is a frame that acts as a container for the entities that
specify the relationship. For one embodiment, relations are
implemented as a combination of a UML package and a corresponding
UML class, which are identified by the same frame and code name and
include the frame identifier and documentation as well as own slots
and axioms specified for that relation. The implementation also
makes use of UML associations to reference the arguments (domain)
of the relation. Relations can be considered arbitrary sets of
finite lists of entities (of possibly varying lengths). Each list
is a selection of entities that jointly satisfy the relation. For
example, the <relation on numbers contains the list <2,3>,
indicating that 2 is less than 3.
[0133] Functions are implemented as special kinds of relations in
one embodiment of the invention. A function frame is a frame that
acts as a container for the entities that specify the function.
Functions are also implemented as a combination of a UML package
and a corresponding UML class, identified by the same frame and
code name, and include the frame identifier and documentation, as
well as own slots and axioms specified for the function. Its
implementation also makes use of UML associations to reference the
arguments (domain(s) and range) and the UML operation representing
the function. For every finite sequence of entities (or arguments),
a function associates a unique object (the value, result, or return
type) to the function. Functions can be considered sets of finite
lists of entities, one for each combination of possible arguments.
In each list, the initial entities are the arguments, and the final
entity is the value. For example, the 1+function contains the list
<2,3>, indicating that integer successor of 2 is 3.
[0134] Note that both functions and relations are defined as sets
of lists. In fact, every function is a relation. However, not every
relation is a function. In a contrast, in a relation, there can be
any number of lists that agree on all but the final element. For
example, the list <2,3> is a member of the l+function, and
there is no other list of length 2 with 2 as its first argument
(i.e., there is only one successor for 2). Alternatively, the
<relation may contain the lists <2,3>, <2,4>,
<2,5>, etc., indicating that 2 is less than 3, 4, 5, and so
forth.
[0135] Unlike KIF, UML allows the arguments of relations and
functions to be named. In the case of variable arity functions, we
recommend that all known, fixed arguments are named. This approach
supports the assignment of roles to arguments of certain
predicates, for example, such as "runner (x) ran to location (y)",
as opposed to ran (x, y). Multiple roles may be assigned to the
same argument a given relation, where required, but in many such
cases, once the role of one argument is provided, it may limit the
roles of other arguments and, therefore, determine the semantics
for that relation.
[0136] Table 5 provides a list of the additional default own slots
implemented in one embodiment of the invention for all relation and
function frames with their mapping to MOF and UML and related
type.
TABLE-US-00008 TABLE 5 Default Own Slots for Relations and
Functions. MOF & UML Slot Metamodel Value Multi- Initial Slot
Name Element Stereotype Type plicity Value Domain Association
domain class * Individual Association individualOf class * Of
Domain Of Association domainOf class * Inverse Of Association
inverseOf class 1 Range Association range class 1 Relation
Association relationUniverseOf class 1 Universe Of
Associating Slots and Facets with Frames
[0137] For one embodiment, each first class ontology frame
(ontology class, relation, function, or individual) has a
collection of slots associated with it. Similarly, each frame-slot
pair has a collection of facets associated with it. A facet is
considered to be associated with a frame-slot pair if the facet has
a value for the slot for that frame. A slot is considered to be
associated with a frame if the slot has a value for the frame or if
there is a value associated with a facet on the slot for that
frame.
[0138] In one embodiment of the invention, slots are only made
visible on diagrams when the user explicitly requests them, such as
when creating an ontology or class overview diagram, or when
specifically creating a diagram depicting the own slots for a
class. This limits the amount of "clutter" on the diagrams for the
sake of readability.
[0139] In one embodiment, a number of utilities may be provided for
users familiar with DAML+OIL/OWL and who are specifically
interested in generating DAML+OIL or OWL from the invention. These
may be related to the DAML+OIL/OWL specific profile layered on top
of the core profile described in section 2.0 and are given in
section 5, below. In one embodiment of the invention, however, a
Create Ontology Slot Wizard is provided for such users who may
prefer that to using a more general Create Relation Wizard.
Foundation Ontology
[0140] Most ontology representation languages and related editors
provide some kind of foundational ontology for use as a basis for
development. At a minimum, many such languages require class
definitions for concepts commonly called entity (also, thing or
top) and absurdity (also, nothing or bottom or null), for language
compliance in the ontologies developed therein.
[0141] In one embodiment of the present invention, there is
provided such a foundation ontology, which defines the concepts,
relations, individuals, and methods that ground the meta-model and
profile. For one embodiment, the foundation ontology is implemented
to support existing ontologies and knowledge representation
systems. For one embodiment, the foundation ontology identifies and
defines a set of concepts and relations useful as a basis for all
ontology development by users. In one embodiment of the present
invention, a mechanism permits users to import one or more upper
ontologies of choice. In another embodiment, a user is required to
select at least one parent class for every concept they define.
That parent class may be as general as entity, but regardless of
the concept selected, at least one may be required. This is a
departure from some knowledge representation systems, but is
necessary for downstream code generation, ontology analysis,
merging, and alignment, and other functions a commercial user might
want to perform. Another goal is to eliminate circular
dependencies, which are rampant in numerous published ontologies,
such as the fundamental ontologies of Ontolingua, the IEEE Standard
Upper Merged Ontology (SUMO), and many of the published DAML+OIL
ontologies available from the DARPA/DAML program web site. Circular
dependencies prohibit code generation, which is one of the primary
features of the present invention.
[0142] FIG. 15 provides a partial, top-level view of the current
implementation of the foundational ontology, following top-level
categories of firstness, secondness, and thirdness, for one
embodiment. FIGS. 16 through 21 show the inheritance hierarchy as
derived from the top level for basic concepts such as relations,
classes, functions, individuals, and slots. While these ontological
components provide an underlying foundation for one embodiment, an
alternative embodiment may align the present invention more closely
with the IEEE Standard Upper Ontology, primarily to enable
interoperability with other formal systems based on that effort and
related work in category theory.
[0143] In accordance with one embodiment, in addition to class
definitions, the foundation ontology includes numerous definitions
for relations and functions, many of which are necessary to support
OKBC compliance. Table 6 provides a list of foundation relations
included in one embodiment of the invention. This list is not
intended to be exhaustive, and may be modified as required to add
new relations to support the Web Ontology Language as it evolves,
to support ISO KIF as that specification matures, or for other code
generation purposes.
TABLE-US-00009 TABLE 6 Foundation Ontology Definitions for
Relations. MOF & UML Metamodel Relation Element(s) Stereotype
Domain(s) Arity Alias Package, alias class 2 Class, Association
CompositionOf Package, binary relation, list 2 Class Disjoint
Package, disjoint, disjunct set 2 Class, Association Disjoint
Package, class, class 2 Decomposition Class partition Documentation
Package, relation, string 2 Class Domain Package, domain relation,
class 2 Class, Association Domain Of Package, class, relation 2
Class Exhaustive Package, class, class 2 Decomposition Class
partition Facet Package, facet continuant 3 Class (?frame),
slotRelation, class (?facetValueType) FrameCode Package, relation
(?frame), 2 Name Class string Frame Package, relation (?frame), 2
Identifier Class string Frame Name Package, continuant 2 Class
(?frame), string Has Default Package, hasDefaultValue relation
(?frame), 3 Value Class, slotRelation, Association continuant
(?defaultValue) Has Member Package, hasMember set, continuant 2
Class, (?member) Association Has Own Slot Package, hasOwnSlot
continuant 2 Class, (?frame), Association slotRelation Has Template
Package, hasTemplateSlot continuant 2 Slot Class, (?frame),
Association slotRelation Has Value Package, hasValue relation
(?frame), 3 Class, slotRelation, Association continuant ((?value)
Individual Of Package, individualOf class, continuant 2 Class,
(?frame) Association Inverse Of Package, inverseOf relation 2
Class, Association Item Package, list, continuant 2 Class (?frame)
Member Of Package, set, continuant 2 Class (?frame) Mutually
Package, set * Disjoint Class Not Same Package, relation (?frame),
3 Values Class slotRelation, collection Nth Argument Package,
relation, continuant 3 Of Class (?argument), positive integer Nth
Domain Package, relation, class 3 Of Class (?domain), positive
integer Onto Package, relation, class 2 Class Pairwise Package, set
* Disjoint Class Partition Package, class, class 2 Class partition
Propcr Subset Package, set 2 Class Range Package, range function,
class 2 Class, Association Range Of Package, function, class 2
Class Range Package, function, class 2 Subclass Of Class Same
Values Package, relation, 3 Class slotRelation Set Of All Package,
continuant 3 Inverse Values Class (?frame), slotRelation, set Set
Of All Package, continuant 3 Values Class (?frame), slotRelation,
set Set Partition Package, set 2 Class Some Values Package,
continuant 3 Class (?frame), slotRelation, set Subclass Of
Specialization class 2 Sublist Of Specialization list 2 Subrelation
Of Specialization relation 2 Subset Of Specialization set 2 Subset
Of Package, continuant 3 Values Class (?frame), slotRelation, set
Superclass Of Generalization class 2 Total On Package, class,
relation 2 Class Type Of Package, typeOf class, continuant 2 Class,
Association Value Type Package, valueType continuant 3 Class,
(?frame), Association slotRelation, class
[0144] FIGS. 22 through 24 provide example class diagrams for
binary, ternary, and variable arity relations, respectively.
[0145] Table 7 provides a list of foundation functions included in
one embodiment of the invention. Again, this list is not intended
to be exhaustive, and may be modified as required to add new
functions to support the Web Ontology Language as it evolves, to
support ISO KIF as that specification matures, or for other code
generation purposes.
TABLE-US-00010 TABLE 7 Foundation Ontology Definitions for
Functions. MOF & UML Metamodel Function Element(s) Stereotype
Domain(s) Range Arity All Instances Package, Class class set 2 All
Values Package, Class continuant set 3 (?frame), slotRelation Arity
Package, Class, arity relation positive integer 2 Association
Cardinality Attribute cardinality continuant nonnegative integer 3
(?frame), slotRelation Collection Type Attribute collectionType
continuant enumerated list 3 (?frame), slotRelation Complement Of
Package, Class set set 2 Compose Package, Class list of binary
relation 2 relations Composition Package, Class binary binary
relation 3 relation Defining Attribute definingCharacteristic
continuant boolean 3 Characteristic (?frame), slotRelation
Essential Attribute essentialCharacteristic continuant boolean 3
Characteristic (?frame), slotRelation Exact Domain Package, Class
relation 2 Exact Range Package, Class class, relation 2 Generalized
Package, Class set of sets set 2 Intersection Of Generalized Union
Package, Class set of sets set 2 Of Intersection Of Package, Class,
intersectionOf set set 3 Association Maximum Attribute
maximumCardinality continuant nonnegative integer 3 Cardinality
(?frame), slotRelation Non-essential Attribute
nonessentialCharacteristic continuant Boolean 3 Characteristic
(?frame), slotRelation Numeric Minimum Attribute numericMinimum
continuant integer 3 (?frame), slotRelation Numeric Attribute
numericMaximum continuant integer 3 Maximum (?frame), slotRelation
Projection Package, Class relation, class 3 positive integer
Relation Universe Package, Class, relationUniverseOf relation class
2 Of Association Union Of Package, Class, unionOf list of sets set
2 Association
[0146] FIGS. 25 and 26 provide example class diagrams for unary and
binary functions, respectively.
Axiom Support
[0147] For one embodiment of the invention, axioms are expressed in
terms of KIF notation. In terms of conformance dimensions as
defined in the draft ISO standard, the subset of KIF that one
embodiment of the present invention will support can be
characterized as follows: [0148] Logical form: rule-like, non-Horn
non-recursive expressions are supported [0149] Term complexity:
complex expressions are supported [0150] Order: first-order
expressions are supported; variables are not permitted in the first
argument of any explicit functional term or explicit relational
sentence [0151] Quantification: quantified expressions are
supported [0152] Metaknowledge: base level expressions are
supported
[0153] In addition, in order to create axiom frames and integrate
expressions in ways that are consistent with the UML profile
defined above, axioms may be named. An axiom frame is a frame that
acts as a container for the axiom and relates the elements of that
axiom to other elements in the model. Axiom frames are implemented
through external files in one embodiment of the invention, and in
some cases are also associated with UML operations. The external
files include the frame name, frame identifier, frame code name and
frame documentation, as well as the KIF expression that specifies
the axiom itself. Persistent storage for these expressions is
provided by an external text file in XML format preserved as a part
of the package (folder in the file system) representing the primary
ontology element (ontology, class, relation, function, or
individual) that the expression is associated with for use by
downstream applications or reasoning systems.
[0154] For one embodiment of the present invention, the set of
valid KIF term and sentence operators that may be used in
expressions are given in Table 8.
TABLE-US-00011 TABLE 8 KIF to UML Term and Sentence Operator
Mapping KIF Operator UML Operator = equals implies implies iff iff
and and or or not not exists exists forall forall
[0155] FIG. 27 depicts the class hierarchy portion of the
foundational ontology supporting KIF expressions.
Knowledge Base Integration and Code Generation
[0156] While the ability to model semantic or conceptual knowledge
in UML, in and of itself, provides significant value, particularly
in light of current trends in web services, collaborative
applications, and so forth, the real utility of the invention is
realized when the ontologies developed can be used in other
applications outside of the modeling environment. The use of
MOF/UML facilitates the exchange of these ontologies with other
tools and tool environments that understand MOF and UML. One
advantage of the present invention is that much of the
functionality to support this level of interchange is already
provided in the UML tools.
[0157] In addition to UML-based interoperability, embodiments of
the present invention support interoperability with existing
knowledge based applications and environments through generation of
(1) an XML file, with terms and structure compliant with the Open
Knowledge Base Connectivity (OKBC), and (2) RDFS, DAML+OIL, and OWL
compliant ontologies. Such facilities can save ontologists and
other knowledge engineers substantial time in developing RDFS,
DAML+OIL, and OWL ontologies in particular, not only in terms of
the initial code development, but in terms of ensuring correctness
by construction and for ontology maintenance purposes.
[0158] Other embodiments of the invention will support more
dynamic, API-based, CORBA, and web services interfaces for the
exchange of either OKBC or RDFS, DAML+OIL, and OWL semantic
knowledge as well as more sophisticated KIF-based knowledge
sharing.
OKBC-Compliant XML Generation
[0159] For one embodiment of the invention, a user initiates a
process for generating an OKBC-compliant XML-based ontology.
Because the generated file may then be imported into a knowledge
base for ontology and instance data management, into other tools
that support evaluation, comparison, alignment, and merging of
ontologies, or may be used by various reasoning systems requiring
complete definition of all terms, the KB and code generator
component of FIG. 2 must generate all definitions not only for the
ontology of interest, but for imported ontologies as well.
[0160] For one embodiment of the invention, a user generates the
XML form of an ontology for an existing UML model by extracting all
UML classes defined in the model (regardless of stereotype) to an
output file using a UML tool. In one embodiment, to generate the
XML form of an ontology, a user initiates a sequence of steps that
perform the following operations: [0161] 1. Load all controlled, or
logical units, not only from the ontology of interest, but for all
included ontologies (i.e., to ensure transitive closure across all
referenced model elements). [0162] 2. Write XML ontology header
information extracted from the UML model properties and related
meta information to the output file. [0163] 3. Loop through all
class, relation and function frames, and for each frame, write the
XML equivalent expression to the file, including all meta
information as defined in frame properties and attributes, own
slots, and own facets. [0164] 4. Step through all template slots
for each frame, writing slot details followed by facet details for
each slot. [0165] 5. Step through all individuals defined for each
frame, writing own slot and own facet details for the individuals
[0166] 6. Step through all axioms defined for each frame, writing
own slot and own facet details for the axioms. [0167] 7. Continue
the process for each class, relation and function frame in the
current ontology, then for each ontology on which the current
ontology depends [0168] 8. Finally, step through any axioms written
at the ontology level, and write own slot and own facet details for
those axioms
RDFS, DAML+OIL, or OWL Ontology Generation
[0169] For one embodiment, the process for exporting an RDFS,
DAML+OIL, or OWL, ontology is slightly different from the process
described above with respect to XML, for a number of reasons.
First, more rigorous attention to format is required, as such
ontologies are publishable to the web for consumption by many tools
that can read these formats. The process will not likely change
dramatically as the invention evolves, except to accommodate
modifications to the OWL specification, particularly with regard to
axiom support.
[0170] Table 9 provides additional DAML+OIL and OWL-specific
profile information required both for modeling and generation of
ontologies that are compliant with these specifications.
TABLE-US-00012 TABLE 9 DAML + OIL/OWL Profile Elements Frame-Based
KR MOF UML (Ontology) Metamodel Metamodel Element Element(s)
Element(s) Stereotype complementOf Package Package relationFrame
(complementOf) Class Class relation (complementOf) Association
Association complementOf disjointWith Package Package relationFrame
(disjointWith) Class Class disjointWith Association Association
disjunct domain Package Package relationFrame (domain) Class Class
relation (domain) Association Association domain hasValue Package
Package relationFrame (hasValue) Class Class relation (hasValue)
Association Association hasValue import (ontology) Dependency
<none used> intersectionOf Package Package
intersectionOfFrame Class Class intersectionOf inverseOf Package
Package relationFrame (inverseOf) Class Class relation (inverseOf)
Association Association inverseOf Ontology Property <none
used> range Package Package relationFrame (range) Class Class
relation (range) Association Association range sameClassAs Package
Package relationFrame (sameClassAs) Class Class relation
(sameClassAs) Association Association sameClassAs sameIndividualAs
Package Package relationFrame (sameIndividualAs) Class Class
relation (sameIndividualAs) Association Association
sameIndividualAs samePropertyAs Package Package relationFrame
(samePropertyAs) Class Class relation (samePropertyAs) Association
Association samePropertyAs subClassOf (rdfs) Specialization
Specialization <none used> subPropertyOf Specialization
Specialization <none used> (rdfs) unionOf Package Package
unionOfFrame Class Class unionOf versionInfo Property <none
used>
[0171] FIGS. 28 through 31 show logical class hierarchies relevant
to the generation of DAML+OIL and OWL ontologies, including
ontology class definitions for RDF Model and Syntax, RDF Schema,
and XML Schema Datatypes. These underlying ontologies form the
layers on which DAML+OIL and OWL ontologies can be developed, as
per the specifications. FIG. 32 shows the logical class hierarchy
for the current version of the OWL specification. The DAML+OIL
logical class hierarchy, which the OWL specification supercedes, is
similar.
[0172] The steps employed by the present embodiment of the
invention to generate the RDFS, DAML+OIL, or OWL form of a UML
ontology include the following: [0173] 1. Create the output file
[0174] 2. Connect to a UML tool, such as Rational.RTM.. Rose, and
extract all classes defined in the model (regardless of
stereotype)--in this case, only for the current ontology. [0175] 3.
Load all controlled, or logical units, for the current ontology.
[0176] 4. Write XML header information required by the DAML+OIL/OWL
specifications, extracted from the UML model properties and related
meta information to the output file. [0177] 5. Loop through
included ontology model properties to extract namespace
declarations for imported ontologies. [0178] 6. Loop through all
class frames, and for each frame, write the XML/RDFS/DAML+OIL/OWL
equivalent expression to the file, including appropriate meta
information as defined in frame properties and attributes, own
slots, and own facets, per the specified format. [0179] 7. For each
class frame, then write all relevant class elements defined per the
RDFS/DAML+OIL/OWL specification, following the basic class
definition, including all rdfs:subclassOf elements,
owl:disjointWith, owl:sameClassAs, owl:sameAs, boolean combinations
of class elements such as owl:intersectionOf, owl:unionOf, and
owl:complementOf, as well as other associations, if any, reflected
in domain associations that aren't reflected in the set of class
elements. [0180] 8. For each class frame, then write all relevant
enumerations and individuals, such as those that participate in
owl:oneOf expressions. [0181] 9. Finally, for each class frame,
write all relevant restrictions based on slot and facet details,
such as owl:allValuesFrom, owl:someValuesFrom, or other
user-defined restrictions pertinent to the class. [0182] 10. Loop
through all standalone property frames (relations and functions),
and for each such frame, write all rdf:Property elements, including
determination of whether they are primitive types (datatype
properties), as determined by the slot valueType relation in
conjunction with the XML Schema Datatypes ontology definitions or
object properties. [0183] 11. For each such frame, write all
relevant property elements defined per the RDFS/DAML+OIL/OWL
specification, following the basic property definition, including
all rdfs:subPropertyOf elements, rdfs:domain, rdfs:range,
owl:samePropertyAs, owl:sameAs, and owl:inverseOf statements.
[0184] 12. For each such frame, then write all relevant property
definitions such as owl:TransitiveProperty, owl:SymmetricProperty,
owl:FunctionalProperty, and owl:InverseFunctionalProperty details.
[0185] 13. Finally, for each such frame, write any remaining
restrictions based on slot and facet details, or other user-defined
restrictions pertinent to the property. [0186] 14. Stepping through
the entire file, insert generated URIs, such as for datatype
properties derived from the XML Schema Datatypes definition, or
other externally imported ontologies, as needed.
* * * * *