Concrete types: next steps?

From: Frank van Harmelen (
Date: 01/31/01

After the teleconf last night, I've tried to summarise the current situation as I perceive it. Perhaps this is useful to find a way forward.


- It is widely accepted that concrete types are a must for any realistic ontology language. 
- Currently the only proposal on the table is the one by Ian & Peter. 
- Its most contentious aspect is the strict separation of abstract and concrete types. 
- The main reason for the separation is that this enables efficient sound and complete reasoning. 
- This claim is apparantly widely accepted within the DL community. 
Question for Ian: can you provide an example of what goes wrong witout the separation?

[So far, nothing to disagree with, I guess:-)]

- a (lesser) complaint (mostly raised by Jeff) was the duplication of syntactic constructs for abstract and concrete types, but this complaint was not as essential, and could also be relieved to a certain extent. 

[Question: is this correct?]

- The separation disallows various constructions:
[1] construct "mixed classes" which are a combination of abstract classes and concrete types. 
[2] use such mixed classes as the domain of properties
[3] use such mixed classes as the range of properties
[4] construct subclasses of concrete types by defining a relation with a non-concrete types (Pat's example of "all salary scales in my company")

[Question: are these correct? are these all?]

- Some (Tim, Dan) claim that such expressions are essential to future uses of the language
- Others (Deb) claim that in their practical modelling experience, they were never significantly hindered by the separation

[Tim, Dan, Pat: can you come up with convincing examples/experiences?]

- The severity of the restriction also depends on the perceived goal of DAML+OIL: [a] is DAML+OIL simply a small step to extend current web-ontology languages (eg. RDF Schema), and will DAML+OIL itself again be extended?
[b] or is DAML+OIL itself aiming to be a language for "universal use" that should empose as little restrictions as possible? 
In case [a], all we need worry about is whether the current restriction will hinder future extensions that might lift the restriction (either theoretically or pragmatically (invested effort in tools etc). 
(Exercise: do a headcount,and (unsurprisingly) you will find that people who take view [a] tend to favour the separation, people who take view [b] strongly object to the separation). 

- One possible way out of the dillemma I proposed would be to define a language 
[i] which allows mixing of concrete and abstract types, but
[ii] where the language which does not mix the two is a proper syntactic subset 
[iii] where this subset can be recognised in a computationally feasible manner.
- An alternative way out (proposed by Ian) would be to do [i], but not insist on [ii] and [iii], provided that reasoners can spot when we are mixing concrete and abstract types, so that users can be warned/computations can be aborted, etc. 
- The difference between these two alternatives is whether the mixing is spotted at parse-time or at reasoning-time. 
- The first alternative is clearly preferable, but we do not know if this will be feasible. 

- Another possible way out is for someone to work out a more liberal proposal, so that we can study the pro's and con's.

[Dan: you were rumoured to have such a proposal almost done?]

This archive was generated by hypermail 2.1.4 : 04/02/02 EST