An Introduction to OilEd
Author: Angus Roberts (angus@cs.man.ac.uk)
OilEd version: 3.3a
Document version: 1.0
Table of Contents
- Introduction
- Installing OilEd
- Getting started
- Adding classes
- Properties
- Simple property restrictions
- Using the reasoner
- Adding individuals
- Sets
- SubclassOf / SameClassAs
- Frames
- The expression editor
- Axioms
- Restriction type - has-class and to-class
- Restriction type - cardinality
- Moving on - further information
Introduction
About OilEd
OilEd is a simple editor that allows the user to create and edit OIL ontologies. The main intention behind OilEd is to provide a simple, freeware editor that demonstrates the use of, and stimulates interest in, DAML+OIL. OilEd is not intended as a full ontology development environment - it will not actively support the development of large-scale ontologies, the migration and integration of ontologies, versioning, argumentation and many other activities that are involved in ontology construction. It should, however, provide enough to allow the basic construction of OIL ontologies and demonstrate the power of the connection to the FaCT reasoner.
OilEd has been built by The Information Management Group, Department of Computer Science, University of Manchester, and is copyright University of Manchester. The original development of OilEd was supported by Interprice GmbH and the Free University of Amsterdam.
Aims of this guide
These are the aims of this guide:
- To provide a step by step tutorial guide to the basics of using OilEd
- To show you some of the functionality of OilEd
- To show you how to use the reasoner with OilEd
These are NOT aims of the guide, and are the subject of other guides and resources:
- To provide an OilEd manual (a basic manual is provided in the OilEd installation directory)
- To teach you about description logics (Try the Description Logic page for this)
- To teach you the DAML+OIL formal language (you can find this out from the Oil home page and the DAML home page)
- To teach you how to design ontologies and model them in DAML+OIL (this will be the subject of future guides)
To reiterate, we want to show you how to press the buttons in OilEd - not how to design and build models. Our example model is very contrived to make use of all OilEd's capabilities. It is not a good example of model design!
This guide assumes that:
- You are familiar with your operating system (screenshots and some instructions assume you are using MS-Windows)
- You are familiar with standard GUIs and their conventions
- You are not phased by basic logic
This guide takes the form of a simple tutorial exercise, building a small (and contrived!) ontology of animals. The guide will show you how to create this ontology, how to add things to it, and how to perform reasoning. The guide has been written with the intention that you follow it step by step. We write examplesfor you to do follow this:
Example
- Do this
- then this
- then this
And other information like this:
Tips and additional information
We write tips and additional information like this. These are things that that may be useful or of interest, but which are not required to use OilEd.
Installing OilEd
Requirements
- OilEd requires Java 1.2
- OilEd comes bundled with a reasoner - using without the reasoner gives only limited functionality
Installing
- OilEd comes as a gziped tar archive - unzip it with your favourite zip utility into a directory of your choice.
- If you would like to start OilEd from menus, desktop icons etc, then make these for:
- OilEd itself: [installation directory]\oiled.bat
- The reasoner: [installation directory]\reasoner\win\scripts\Reasoner.bat
Uninstalling
- Delete your installation directory
- Remove any shortcuts and menu items you might have added
- OilEd does not make any changes to any registries or system config files
Getting started
Start OilEd
Start OilEd by running the file oiled.bat in your installation directory, or by using any shortcut, icon or menu item you created during installation.
Creating and saving models - the file menu
Create a new model, using the file menu. As soon as you have created a new model, save it somewhere safe:
Example
- File
- New
- File
- SaveAs model...
The file menu contains several options for opening, closing and saving models, shown and described below:
Saving
You should save your work frequently and regularly when using OilEd. You may also like to save consecutive versions of your work under different names (eg using some sequential numbering scheme). This is particularly necessary when you begin using the reasoner (see below), as this makes it easy to overwrite your model with a version altered by the reasoner
Saving in different formats - exporting
When you save, DAML+OIL is used by default as the representation format. Use the Export menu if you wish to save using a different format. Supported formats may vary, but can include documentation style HTML, Dotty (AT&T's grapher), RDFS, and the SHIQ and SHOQ(D) languages used by the FaCT reasoner
Including Ontologies
Ontologies can be included. When an ontology is included, any classes, properties and individuals not already in the ontology will be added along with their definitions. If information in the included ontology relates to an existing class (for example, the included ontology may also contain a definition for a particular class), that information will be added as an axiom if the existing class already has a definition. No attempt is made to prevent duplication, and no check is made at inclusion time that conflicts are not being introduced.
The main OilEd window
The main OilEd window contains two sets of tabs. Along the top is a set of tabs that allows you to switch between different aspects of the current model, and to switch to any plugins you may have installed:
Along the bottom is a tab that allows you to switch between several open models, and a message bar:
Model metadata - the container tab
A small amount of information about your new model can be provided in the container tab. Switch to the container tab and add some details.
Example
- Choose the container tab
- Click on the pen button to edit a field
- File
- Save
Click on the pen button to edit a field
Adding classes
The Class tab and menu
Classes are added in the Classes tab. The left hand pane is a list of your classes, and the right hand pane provides an editor for describing the selected class. Basic operations on the selected class are provided by a mouse menu in the class pane, as shown and described below:
Add some classes
We will build a small model of animals. First, we will add some animals. We will not add any description, other than to say that some of our animal classes are subclasses of others.
Example
- Choose the Classes tab
- Right click in the Classes list to open a mouse menu
- Choose Add Class
- Type animal for the class name
- Select animal to highlight it
- Right click in the Classes list to open a mouse menu
- Choose Add Subclass
- Type cat for the class name
- In the same way, add giraffe, sheep and cow as subclasses of animal - make sure animal is highlit before you add each one
- In the same way, add mad cow as a subclass of cow - make sure cow is highlit
Describing classes
When a class is selected, you can describe it in the right hand class editor pane. You can also spawn this editor from the class pane mouse menu. A spawned editor is shown below, with a description of each element:
Viewing the class hierarchy
You can view the classes as a tree, in a class hierarchy view window. This has a pane containing the tree view, and one listing the superclasses of the class selected in the tree.
Example
- Double click on any class, or choose "show hierarchy" from the mouse menu
- Open and close branches of the tree in the usual way
Properties
The Properties tab and menu
We want to describe some properties of our classes. Before we can do this, we must define the properties we will use.
Properties are added in the Properties tab. The left hand pane is a list of your properties, and the right hand pane provides an editor for describing the selected property. Basic operations on the selected property are provided by a mouse menu in the property pane, as shown and described below:
Adding some properties
Add a couple of properties as follows:
Example
- Choose the Properties tab
- Right click in the Properties list to open a mouse menu
- Choose Add Property
- Type eats for the property name
- In the same way, add eaten by as a new property
Describing properties
You may describe several aspects of a property, such as super properties, inverses, domains, ranges, documentation, transitivity, in the right hand property editor, shown below:
Describe the properties you have just added:
Example
- Select the eats property
- In the inverses panel, add eaten by as the inverse using the "P" button
- In the domain panel, add animal using the "class" button
- Repeat these steps for eaten by, but add eats as inverse and animal as range
Property datatypes
In the above example we defined properties as having
ranges of DAML+OIL classes. DAML+OIL also supports property
ranges of XML Schema datatypes. OilEd has some support for this - if
you choose the "set datatype" option on the properties menu of a new
property, then the usual range toolbar is replaced with a datatype button:
Selecting this
gives you a list of XML Schema datatypes to choose from.
Simple property restrictions
Now that we have some properties, we can start to describe classes. We will begin with a couple of simple class restrictions, using the restrictions panel of the class editor:
The restriction panel has four tool buttons:
 |
Copy restriction |
 |
Paste restriction |
 |
Add restriction |
 |
Remove restriction |
A restriction is made up of a property along which the class is restricted, the type of filler for the property, and a filler for the property. When you select "Add restriction", you are given a choice of properties along which to restrict the class:
Once you have chosen a property, you are asked to select a filler type:
|
Filler is a class |
 |
Filler is a class description (frame) |
 |
Filler is a set of individuals |
 |
Filler is an expression |
 |
Filler is of class Thing, i.e it can be anything |
Most of these will be explained later. The simplest, which we will use now, is to allow a property to be filled with a class. If you select this, you will be given a class selector as shown below:
Now we will create some simple class descriptions:
Example
- Return to the Classes tab
- Select animal
- Add a restriction along eats
- Select filler type of Thing
- Add two more classes, dog and bone. Add these without any superclasses, so that dog is not a subclass of animal
- Select dog
- Add a restriction along eats
- Select filler type of class bone
If you now open the class hierarchy viewer, you should have a hierarchy like the one below. Note that dog is not a subclass of animal, because we didn't describe it as such. We would like to use our description of animal and our description of dog to work out that dog is classified as a subclass of animal. To do this, we will use the reasoner.
Using the Reasoner
In order to classify concepts according to the properties we have modelled, we need to connect OilEd to a reasoning service. This is provided by the FaCT reasoner, which is installed with OilEd.
Starting the FaCT reasoner
Start FaCT by running the file reasoner.bat that you installed with OilEd, in [installation directory]\reasoner\win\scripts\Reasoner.bat. Alternatively, use the menu, icon or shortcut that you created at installation.
What are all the windows?
Starting FaCT opens up several windows. FaCT is implemented in Lisp with a CORBA interface. A Java server has been written to connect networked clients to the FaCT server. Hence the windows.
Connecting to and using FaCT
Once FaCT has been started, you must connect OilEd to it, before you can make use of its reasoning services. Use the five rightmost toolbar buttons to connect to and use FaCT:
To connect to FaCT:
Example
- Make sure you have started the FaCT server
- Connect to FaCT using the green "F" button
- In the connection dialog, use the defaults of Host: localhost and Port: 8000, select OK
- OilEd should display the message "FaCT is alive and well" in the bottom left message panel
The other buttons on the toolbar are used to control OilEd's interaction with FaCT, as listed below, and as explained by the small example following.
|
Connect to FaCT |
 |
Disconnect from FaCT |
 |
Verify model, asking reasoner to determine hierarchy |
 |
Commit superclass relationships discovered by reasoner to model |
 |
Forget superclass relationships discovered by reasoner |
Example
- Make sure you are connected to FaCT
- Verify the model using the verify toolbar button
- Examine the hierarchy - you will see that dog is now correctly classified under animal, as shown in the screenshot below
- Discard FaCT's results using the discard toolbar button
- Examine the hierarchy - the previous classification by FaCT has been discarded, and your hierarchy has reverted to dog not being classified under animal
- Verify the model again
- This time, commit FaCT's changes to your model, using the
commit button
- Look at the description of dog in the class definition pane - FaCT's inferred superclass of animal has been placed in your model
Inconsistencies
If the reasoner finds any logical inconsistencies in your model, it will mark the inconsistent class as a red icon:
We will see an example of this when we look at axioms later.
Why did the classification work?
If you know a little about DAML+Oil already, you may have spotted a small cheat we used to make this work. It is not only the description of dog that was used by the reasoner to classify it: the fact that we had set a property domain, i.e. an axiom, was also used. In general, such classification does not work unless you also use the SameClassAs property, to set conditions as necessary and sufficient. SameClassAs is described later in detail.
Adding individuals
As well as defining classes, you can define individual members of classes in OilEd. Individuals may be members of previously defined classes, or of arbitrary classes defined using other tools such as the frame editor and the expression editor.
Individuals are added in the Individuals pane. A mouse menu is used to carry out operations on the currently selected individual. This is shown and described below:
We will add a new class and some individual members of that class to use later:
Example
- In the classes pane, add a class heavenly body
- Move to the individuals tab
- Right click in the left hand individuals pane to open a mouse menu
- Select Add Individual
- Add an individual called sun
- In the right hand individual definition pane,
say that sun
is an instance of class heavenly body,
by using the Class button
- In the same way, add other individuals of class heavenly body called moon and mars
What else can you define with individuals?
The expression and relations list panel allow editing of the individual's definition and a popup menu on the individual list allows addition, removal and renaming as with the class and property panels. Relations to other individuals can be added and removed. If a datatype property is selected, a datatype value can be entered. This must be explicitly typed. OilEd does not check that the values supplied are sensible.
Sets
It is sometimes useful to describe a filler by explicitly enumerating the individuals that can be used, as shown in this example:
Example
- Move to the properties tab
- Add a property called howls at
- Move to the classes tab
- Add a class called wolf with no superclass (not animal or dog for this example)
- Add a restriction along howls at
- Give a filler type of set, using the set button
- You will be given a list of individuals to choose from (see figure below) - choose moon
Defining bigger sets
If wolves howled at mars as well, you could have selected a bigger set of both the moon and mars (or any other individual) by shift and ctrl clicking.
Where else can you use sets?
Anywhere you might use a class. A set describes a class by enumerating its membership. You can use a set for slot fillers, superclasses, property domains and ranges etc.
SubclassOf / SameClassAs
In the top right of the class editor pane, there are two radio buttons for setting properties of a class:
All the classes we have defined so far have used the default SubclassOf property. This is equivalent to saying that our descriptions are necessary conditions - all members of the class will necessarily meet these conditions.
This is not the same as saying that anything that meets these conditions will be a member of the class. SubclassOf conditions are not sufficient to define membership. For this, we need to use the SameClassAs property.
Necessary, sufficient
We can summarise the difference as:
SubclassOf |
SameClassAs |
| Necessary for class membership, but not sufficient to describe membership | Necessary for class membership, and sufficient to describe membership |
| Primitive class | Defined class |
This is explained in the following example and discussion:
Example
- In the classes tab, make a new class person, with no superclass
- Make a new class werewolf as a subclass of person
- Add a restriction to werewolf with property of howls at and a filler type of set with a single member of moon
- Verify the model
- Look at the class hierarchy. werewolf appears under person, but even though it howls at the moon, it does not appear under wolf
- Select wolf
- Change the Property setting from SubclassOf to SameClassAs
- Verify the model
- Look at the class hierarchy - Werewolves are now both man and beast
Explanation
In the first example, we had a description of wolf with a property of SubclassOf and a restriction of howls at moon. Because this description is SubclassOf, it is a necessary but not a sufficient condition. This means that all wolves will howl at the moon, but not everything that does so is a wolf: it is not sufficient to only howl at the moon to be a wolf.
Once we change wolf to SameClassAs in the second example, we are saying that our description is necessarily true of wolves, and a sufficient condition to describe wolves. All you have to do to be a wolf is meet this condition. So werewolves, by meeting this sufficient condition, are wolves.
When to use SameClassAs?
OilEd defaults to using SubclassOf. So when should SameClassAs be used? This is an important decision in ontology design. SameClassAs is often referred to as a "defined" description, i.e. a complete definition. SubclassOf is often referred to as a "primitive" description, i.e. we either cannot or choose not to give it a complete definition. Instead, we give it a description by which it can be classified under other fully defined classes.
Frames
So far, we have used single classes and simple sets of individuals as fillers.
It is possible to use any arbitrary class description as a filler - using the
frame description editor, opened with the
toolbar button and shown below.
The example in this screenshot was made as follows:
Example
We will create an arbitrary class of big bone and use it in our description of wolf:
- In the classes tab, add a new class of size with subclasses of big and small
- In the properties tab, add a new property of has size with a range of size
- In the classes tab, select wolf
- Add a restriction along property eats
- Add a filler type of class description (frame)
- In the frame description editor, add a superclass of bone
- Add a restriction along property has size and filler of type class, big
- Select OK to confirm the new description
- Make sure dog has its properties set to SameClassAs
- Verify and examine the hierarchy - wolf now appears under dog as they eat bones. But werewolf is no longer under wolf, because we have said nothing about their eating habits.
Where else can frames be used?
Anywhere. Wherever you might use a class, you can create an anonymous class using the frame editor - slot fillers, superclasses, property domains and ranges, and to describe the class of individuals.
The expression editor
As well as the frame description editor, we can also use the OilEd expression editor
to create arbitrary expressions as fillers. Among other things, the expression editor
allows us to use negation, conjunction and disjunction to build complex expressions
combining classes, individuals, and frame descriptions. The expression editor is
opened with the toolbar button,
and is shown below:
The editor uses a tree to display the structure of the expression - the example shows a conjunction with a class name and an arbitrary frame as arguments. Subexpressions can be expanded and collapsed using standard tree controls. The root of the expression can be reset using the buttons at the bottom of the screen (note that because these replace the root of the expression, they replace the entire expression):
|
Class, picked from class selection list |
|
Frame, using frame description editor |
|
Set of individuals, picked from individuals selection list |
 |
Conjunction - add arguments using the mouse menu (shown below) |
 |
Disjunction - add arguments using the mouse menu (shown below) |
|
Thing - any class |
 |
Nothing - no class |
A right button menu gives access to various operations on the selected part of the expression. The "add argument" menu allows arguments of various types to be added to conjunctions and disjunctions:
We will add a new restriction to werewolf, to say that they eat bones which are big and from person
Example
- In the properties tab, add a new property from species
- Select werewolf in the classes tab
- Add a new restriction along property eats
- Give the restriction a filler type of expression using the expression button
- Select the top of the current expression - this will be Thing, because the expression is initially anything
- Click on the conjunction button
to change the expression root
- Select the new root
- Right click and choose "add argument - class" from the mouse menu
- Choose the bone class from the class selection list
- With the root selected again, right click and choose "add argument - frame" from the mouse menu
- Fill in the frame description editor to create a concept with no superclass and the following two restrictions, so that it looks like the screenshot above:
- Add a restriction to the frame along has size with filler big
- Add a restriction to the frame along from species with filler person
- Select OK
- Verify the model, and examine the class hierarchy - werewolf is now classified under both person and wolf, due to their disgusting eating habits and nocturnal noises
Where else can expressions be used?
As with frame descriptions, anywhere. Wherever you might use a class, you can create an arbitrary expression using the expression editor - slot fillers, superclasses, property domains and ranges, and to describe the class of individuals.
When do you use expressions?
The above example could have been created as a single frame. In addition, simpler concepts could have been created and then composed together to make our final concept. As with much modelling, it is a matter of style and preference as to how you model particular concepts. Very complex expressions are not often seen. However, OilEd does open the expression editor when editing existing restrictions and other constructs - try right clicking any simple restriction and choosing "edit filler"
Axioms
You can create several types of axioms within OilEd - statements which you define to be true of the classes in the ontology. Axioms are created in the axiom pane. A mouse menu is used to add axioms:
Properties of axioms are defined in the right hand pane.
Disjoint axioms
We will demonstrate disjoint axioms by first making a deliberate mistake. We will create a new class lion and say that it eats something which is sheep and cow, when we should have said sheep or cow. We might think that the reasoner should spot this and say that lion is inconsistent:
Example
- In the classes pane, add a new subclass of animal - lion
- Add a property restriction of type eats, and choose filler of type expression
- Enter an expression of sheep and cow
- Verify your model
lion has been successfully classified. This is because as far as the reasoner is concerned, something could be both a sheep and a cow at the same time, and a lion could eat such a thing. In order to say that sheep and cow are disjoint, we will add an axiom:
Example
- Move to the axioms pane
- Choose "add disjoint" from the right click mouse menu in the axiom pane
- In the disjuncts pane, add the two classes sheep and cow
- Verify the model
The reasoner now reports that lion is inconsistent. They can't eat things that are both sheep and cows at the same time. To correct this bug in our model, change the property restriction on lion:
Example
- Move to the classes pane
- Select lion
- Select the property restriction
- Choose "edit filler" from the right mouse menu
- Change the filler to sheep or cow
- Verify the model
What are disjoint axioms used for?
Disjoint axioms are used to define subclasses as independent of one another, i.e. with no overlaps. As in other parts of OilEd, you don't have to make disjuncts between defined classes. Any arbitrary frame or expression will do.
Subclass axioms
Our hierarchy of animals is currently organised mainly by species. What if we wanted to organise animals along other axes? Or even along multiple axes? We can do this by introducing subclass axioms. These can be used to describe properties that are true of a class, but are not sufficient to define the class.
As an example, we will describe our animals' feet. We will then classify them along this axis using the reasoner:
Example
- In the classes tab, add a new class foot
- Add subclasses of foot, paw and hoof
- In the properties tab, add a new property of has foot with a domain of animal and a range of foot
- In the axioms tab, right click in the axioms pane and add a subclass axiom
- In the expression editor, choose class of lion
- In the superclasses pane, add a frame with a single restriction on has foot and a filler of paw
- Add similar axioms for cow with hoof
- In the classes tab, create new subclasses of animal called hoofed animal and pawed animal
- Give them property restrictions of has foot with appropriate fillers
- Make sure they both have properties set to SameClassAs
- Verify the model
- Examine the class hierarchy
You should now have a class hierarchy that includes the division of animals into hoofed and pawed. Now we will add a second axis, describing animal's wildness:
Example
- In the classes tab, add a new class wildness
- Add subclasses of wildness, wild and domestic
- In the properties tab, add a new property of has wildness with a domain of animal and a range of wildness
- In the axioms tab, right click in the axioms pane and add a subclass axiom
- In the expression editor, choose class of lion
- In the superclasses pane, add a frame with a single restriction on has wildness and a filler of wild
- Add similar axioms for cow, which is domestic
- In the classes tab, create new subclasses of animal called wild animal and domestic animal
- Give them property restrictions of has wildness with appropriate fillers
- Make sure they both have properties set to SameClassAs
- Verify the model
- Examine the class hierarchy
Your class hierarchy should now contain classifications along both axes.
Defining necessary conditions
When we define a class as SameClassAs, we are saying that all the conditions are both necessary and sufficient for membership of that class. What if we want to define some conditions that are only necessary for this same class? We use subclass axioms. In this way, we can use necessary and sufficient conditions (via the SameClassAs property) to define our main hierarchy of classes, and use necessary conditions (via subclass axioms) to define additional axes of classification.
Covering
Subclass axioms are also used to define concept covering. For "independent" concepts like animal, the list of primitive subclasses is usually incomplete: we would not pretend to have listed all subclasses of animal. For other concepts, particularly those that describe values, such as size, we might expect to provide a complete and mutually exclusive list of subclasses. We would model this by providing subclass axioms for all subclasses of the concept, and ensuring that they are disjoint by selecting the "disjoint" check box on the subclass axiom (which is equivalent to creating a separate disjoint axiom).
SameclassAs axioms
You can also define SameClassAs axioms - useful for defining equivalence
Restriction type - has-class and to-class
So far, all the restrictions we have used have been of type "has-class". There are other types of restriction. Restriction type can be changed by selecting a restriction and using the mouse menu:
We will look at to-class restrictions in the following example, and at cardinality in the next section.
Example
- In the classes tab, add a new class of plant with a subclass of grass
- Add a subclass of animal called vegetarian
- Make sure vegetarian is defined as SameClassAs
- Give vegetarian a property restriction of eats with filler plant
- Change the superclass of cow from animal to vegetarian
- Create a new disjoint axiom, stating that plant and animal are disjoint
- Select mad cow and give it a property restriction of eats with filler sheep
- Verify the model
- Examine the class hierarchy
You will see that mad cow appears under vegetarian, though clearly they are not. This is because the has-class restriction is saying that vegetarians are things that eat plants, but does not say that this is all they eat. We need to change the restriction to a to-class one, saying that vegetarians are things that only eat plants:
Example
- Select vegetarian in the classes pane
- Select the restriction
- Right click and choose Change Type then to-class
- Re-verify the model
- mad cow should now be highlighted in red, as it is inconsistent
Restriction types and quantifiers
Restriction types are equivalent to logical quantifiers. As you have probably guessed from the symbols used in OilEd, has-class is equivalent to existential quantification, and to-class is equivalent to universal quantification.
has-value |
to-class |
| existential | universal |
| Some slot has the value | Slot can only have the value, if it has a value |
Restriction type - cardinality
We can also describe a restriction by its cardinality, allowing us to define the number of fillers a slot may have - maximum, minimum or exact number. This is done using the same change type menu as above, via the cardinality sub-menu:
For example, we could define the number of feet things can have:
Example
- In the classes tab, add a new subclass of animal, called biped
- Make sure you set the SameClassAs property
- Add a new property restriction on has foot with filler foot
- Right mouse click on the new restriction and choose "change type", "cardinality", "exact"
- Give the cardinality a numerical value of 2
- Select class person
- Create a new restriction on has foot with filler foot
- Right mouse click on the new restriction and change the type to have a cardinality of exact 2
- Verify the model
- Examine the class hierarchy - person should appear under biped
What else can you do with cardinality?
The reasoner will behave sensibly with min, max and exact. So you could define a class of things with minimum 3 feet, and person would classify under it. Similarly, you could define things with more than one foot, and person would classify under it.
Moving on - further information
OilEd functionality we have not covered
These are the bits of OilEd functionality we have not covered:
- Namespaces
- Transitive, symmetric, and unique properties
- Logging and change files
Further information
Building Ontologies
Here are some general papers and resources on ontology building:
- Alan Rector's paper on Untangling Taxonomies and Relationships, although not based on DAML+OIL and concentrating on medical ontologies, does however explore some of the issues and design decisions in large description logic ontologies.
- Stanford's guide to Ontology Development, is geared towards Protege and frame based ontologies
- Asunción Gómez-Pérez has a large collection of presentations overviewing ontology methodologies and engineering
- February 2002 Communications of the ACM was a special issue on Ontologies. Visit the ACM and check on their Digital Library link
The Semantic Web and DAML+OIL
- A brief introduction to the semantic web and Oil, with some useful links as jump off points
- The Semantic Web site has a huge number of links
-
If you are interested in the formal languages and their definitions, you can get full details of the DAML+Oil and Oil from: