US 20080295068 A1
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.
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
5. The method of
6. The method of
7. The method of
generating code representing the ontology in a language specific to a particular knowledge representation format.
8. The method of
9. The method of
10. The method of
11. The method of
12. The method of
13. The method of
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.
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”).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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):
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.
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.
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.
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.
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”).
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.
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”)).
A role ontology may define terminology and concepts relevant for a particular end-user (agent, person, application, or resource).
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.
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).
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.
In an exemplary embodiment, a computer system, such as that illustrated in
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.
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.
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.
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.
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.
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.
Referring once again to
In one embodiment, the present invention is implemented to work over a network of computers, as illustrated in
The flow diagram of
Further details regarding an exemplary add-in component 700 are shown in
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.
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.
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™, 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.
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.
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.
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.
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.
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.
Add-in component 700 of
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.
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.
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.
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.
In one embodiment of the invention, the following naming convention are used with respect to frame names:
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.
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.
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.
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.
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:
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.
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.
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.
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® ClearCase®, 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.
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.
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.
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.
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.
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.
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.
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’.
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.
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.
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.
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.
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.
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).
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,
(<=>(holds ?C ?I) (individualOf ?I ?C))
The relation typeOf is defined as the inverse of the relation individualOf. That is,
(<=>(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,
(<=>(superclassOf ?Csuper ?Csub) (subclassOf ?Csub ?Csuper))
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:
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.
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)).
In general, the following facet value inheritance axiom holds for the relation hasValue:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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:
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.
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.
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.
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.
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.
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
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:
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.
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.
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: