Ontology Server Functionality

The metadata meeting on 3/4/03 discussed ideas behind Ontology Servers.

We know from our previous experiences that there are different kinds of service that an OS can provide. These include:

• Conceptual services. Access to, for example concept hierarchies or classification of arbitrary concept expressions.
• Lexical services. The ability to associate natural language terms with concepts and properties and then generate nl from concept expressions. Also the ability to go from terms or strings to concept expressions.
• Extralogical services. There are many of these which come under the general banner of "extrinsic" services. We can in addition identify at least two further classifications of this kind of information:
  • Metamodelling. By metamodelling here, we refer to the kinds of information which it is useful to store and record about an ontology which is "extra-logical". It is extra-logical in that it does not impact on the classification of the classes in the ontology, but it is still information that should be associated with the ontology rather than any particular application view. For example, "Dublin Core" style metadata like authorship or creation date.
  • Domain extrinsics. Here, we consider information that particular applications may wish to associate with an ontology, but which is again extra-logical in that it does no impact on the classification hierarchy, but which is possible useful to a number of applications. So an example of this would be the kind of "reasonables" information that allows us to drive user interfaces from an ontology. Or information that describes a particular class as being abstract -- i.e. we do not wish to see instances of that concept. In this particular case, such information could be application specific.

A further concern expressed by both Alan and Carole was that we should not preclude ourselves from using alternative representations of ontology, e.g. frame based representations. In other words,

Ontologies ~= OWL.

This is not something I would wish to enforce, but I would like to see us providing a clean separation and characterisation of the kinds of information that we do expect to represent, so that we can be clear when we can and can not expect things like reasoning to occur. I would also like us to use OWL wherever possible.

So for example, we should be able to support models where we expect default reasoning to occur (e.g. restrictions may not supply the definitions of classes, but may instead be specifications of the default values we expect to retrieve).

An initial suggestion was that we could provide alternative semantic "views" of the ontology, e.g. a DL one or a frame one, where each view would make different kinds of inference about the ontologies.

From the discussion that we had, though I believe that it is possible to support this kind of thing with a single approach to the semantics and through the appropriate identification of where we expect the different kinds of information to occur. This would involve providing a number of different interfaces:

• Concept Representation. The basic stuff that makes up the ontology.
• Semantics. Access to inferred taxonomies and inference.
• Extrinsics. Access/manipulation of extralogical information.
• Language. Access/manipulation of langauge functionality.

This is similar to the original GALEN view of the Terminology server providing a number of different "modules", each of which might use the others to calculate the results of queries. One difference here would be that questions like "sanctioning" which in GRAIL were bound up with the concept representation, would instead be handled as extrinsics.

(We have based our initial design for an OWL API on this kind of split, and as discussed in our (forthcoming) ISWC submission, this can alleviate some of the problems that we have experienced in the past.)

Take the case where we have a Protege-style implementation that allows us to assert a basic taxonomy and then provide slot filling values for classes. These are to be treated as defaults (rather than definitions) and can override restrictions applied higher up the taxonomy. In this case, the implementation would implement the appropriate parts of the Semantics and the Extrinsics interface. It would then be explicit as to whether information being added to the model would, or would not, have an impact on the classification. In this case, the defaults would be treated as extrinsics rather than class definitions.

Diagrams to follow....

-- SeanBechhofer - 07 Apr 2003