From: Frank van Harmelen (Frank.van.Harmelen@cs.vu.nl)
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. Frank. --- - 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