In this post I'll discuss a deceptively simple exchange in a dialogue and discuss how we can use OWL to understand that the answer is valid.
The exchange is as follows in natural language:

Agent: What is the purpose of ontology O?
Author: Ontology O aims to support the annotation of geographical objects.

The equivalent dialogue in Manchester syntax would look something like the following (assuming we have defined all the used entities in advance in some context ontology):

In my previous post I proposed to introduce a vocabulary to make it easier for a dialogue participant to find out more about a particular OWL entity. In this post I'll explore this solution a bit further, as it is an unusual way to use OWL: the language is used as if it were a command language, instead of strictly encoding knowledge or defining a vocabulary. I'll try to give arguments for and against using the proposed solution.

The example I gave was:

In this post I'll discuss a couple of dialogue scenarios based on the elicitation of ontology purposes. More specifically in this scenarios I'll assume that all the dialogue is performed using only OWL as the communication language.

Background and motivation

When specifying dialogue moves for a dialogue agent, it is often useful to write conditions in terms of what the dialogue participants know (or are expected to know). Unfortunately, OWL (1 and 2) don't have any standard provisions for easily modeling this type of assertions. In this post I'll explain the problem using an example and discuss some of the solutions (all of the solutions are better known as metamodeling).

The Problem

Since a couple of weeks I've been playing around with the idea to build a linked data repository/expert system for keeping track of recipes. The cooking domain seems like a good area where linked data, ontologies and information extraction should be able to produce a useful system.

First of all, the WWW is full of recipes that are easy to find. The language used in these recipes is fairly restricted: it's mostly ingredients (sometimes with specifications as to how they should be prepared, i.e. chopped, minced, etc.), quantities, and the steps to cook the the ingredients.

A while back I had a quick look at FluidDB, an exiting new database. Terry Jones, the main developer of FluidDB, wrote two excellent blog posts at O'Reilly Radar. Here's I'll write down an initial comparison between FluidDB and the Semantic Web.

I describe the difficulty of finding (equivalent or more specific) alternatives for axioms containing universal object property restrictions in OWL in such a way that OWL reasoners can infer the original axiom. Let the target axiom be:

Individual: x Types: p only A

The problem here is that the open world assumption makes it hard to replace this axiom with a single alternative. For example, if we know that

Individual:a Types: A

we could try replacing the target axiom with

Individual:x Facts: p a

I've been busy the last couple of days implementing a new functionality that I need for the Ontology Purpose Elicitor. For now I'm calling the new functionality the Concrete Level Finder, although this is very specific for the dialogue context. I'll try to explain the problem I am trying to solve. In a next post I will explain how I'm solving the problem.

In the context of the elicitation of ontology purpose through a dialogue interface, the goal of the dialogue agent is to find axioms of the following type:

Individual: ontologyX Types: IntendedOntology

A group of 20 from the School of Computing went to Bletchley Park on Saturday, and I was one of them. It was really interesting to hear and get a better understanding of the situation during the second world war. We didn't have time to see everything that they have on show although we did two guided tours. The first was a guided tour about the history of the park and the code breaking that took place there. The second tour was at the National museum of computing, which now occupies one of the buildings at Bletchley Park.

Yesterday I had to implement a copy-replace method for the OWLAPI. There were some options to reuse code, but in the end they didn't seem suitable. I'll go through the options I considered.