University of Manchester Check out the web site… Sean Bechhofer University of Manchester http://oiled.man.ac.uk

Why OilEd? Not a fully-fledged ontology editor. Not a knowledge base construction tool. Low cost, easy editor. Increase awareness of OIL & DAML+OIL. Demonstrate full expressive power of OIL & DAML+OIL. A platform to explore how to use the reasoner. First be clear about what OilEd is not. Wanted to get something out quickly that would promote the use of OIL and provide a demonstration that reasoning can be useful. A “quick n dirty” job. Not intended to be a world beating ontology editor, or a kb construction tool, or any kind of rival to existing tools (e.g. Protégé). In my opinion, we need to build lots of these things and send them out. <CONTROVERSIAL> Standardisation of representations is good, but questionable for tools. </CONTROVERSIAL>

Interesting Features Arbitrary class expressions can be used as slot fillers. Extending the frame-based paradigm. Boolean connectives. Primitive & defined classes. A number of slot constraint types. Explicit quantification. Slot hierarchies. Concrete type expressions. Axioms Disjointness, covering and equality. Possibility of using a reasoner. What makes Oil interesting in this context? First point is the use of arbitrary class expressions as, for example slot fillers. Primitive & defined, e.g. necessary and sufficient conditions. Slot hierarchies – not terribly difficult to deal with, but something that’s not generally found in frame languages. The reasoner – this is really the interesting bit (as far as I’m concerned).

Why a new Tool? Existing ontology editors suffered from: Lack of Expressiveness Lack of Reasoning Provides a platform for (implementation) experiments. How do we integrate the results of reasoning into an editor? Protégé as it stands (or as it stood), didn’t support things like allowing arbitrary expressions as slot fillers. Also no connection to the reasoner. So Protégé didn’t support what we wanted to do. Why not extend/amend Protégé? We only had a couple of months to do it, and reckoned that it would require a fairly detailed knowledge of the underlying classes – Stanford couldn’t do it and such an exercise is very difficult to do remotely. Also, we wanted to experiment with the use of the reasoner, and rolling our own made this easier. Also provided us with a certain amount of freedom from the problems of using a legacy system. Remember again, that our prime motivation here wasn’t building a wonderful ontology editor, but investigating some of the issues. We are now considering how to bring together the techniques employed in OilEd with Protégé.

OilEd Philosophy Tabbed panes for classes, slots, individuals and axioms. Basic component is the frame description Specifies superclasses and slot constraints. Controls for addition, removal and editing of superclasses and constraints Different editors for different expression types Classnames Frame descriptions One-of Expressions Simple hierarchical views. No frills. The frame description appears everywhere and is the basic thing used for representing expressions. Different editors for different expression types. This does introduce some difficulties with migrating expressions, but was a relatively easy solution to implement – again expediency was the key.

Reasoning KB translated to equivalent DL model, and passed to a reasoner (FaCT/RACER/Cerebra). Spots inconsistent definitions e.g. contradictions in cardinality constraints or value restrictions. mad cows! Organises the classification hierarchy Discovering new superclasses. Particularly useful when using defined classes. Subtle side-effects Superclasses inferred due to domain/range restrictions. One shot connection to the reasoner. Allows temporary inconsistency What does reasoning provide us with? The ability to spot inconsistent descriptions and definitions, which can occur in a number of ways. Classification of hierarchies. Which can then be dumped out for other, OIL-aware applications that don’t reason, or RDF-aware applications that don’t OIL. We do have to be careful about the way that things work. For example, if we say that a particular role has a domain restriction, then anything using that role will be inferred as being a sub of the filler of that restriction – this may not be what you expect.