Re: Concrete types: next steps?

From: Frank van Harmelen (
Date: 02/06/01

At the risk of being incredibly naive, I suggest that there is a fairly easy way out of this:

[1] We adopt the proposal from Ian and Peter

[2] This commits us to a semantics for the strictly separated use of  "predefined" and "user-defined" classes (my attempt to use better names than abstract and concrete), 

[3] However, the schema definition still allows to freely mix predefined and user-defined classes (since RDF isn't powerful enough to enforce the separation,  even if we wanted to).

[4] The language with separation is a sublanguage of the language that allows mixing (in the sense all correct expressions of the first are correct expressions of the second, but not vice versa). 

[5] Fortunately, it seems fairly easy to detect when a set of expressions in DAML+OIL+types violates the separation (this remains to be determined for sure). 

[6] We then have a nice layering of languages as follows:

    RDF Schema < DAML+OIL < DAML+OIL+types[separated] < DAM+OIL+types[mixed]

This should satisfy everyone: whether you believe that we are simply extending existing Web languages in small steps, or whether you believe that we are building a Universal Web Language, we all agree that the architecture should be one of layers of languages, with as much "partial understanding" between the layers as possible (in the sense that RDFS-only agents can partially understand the meaning of a DAML+OIL document (and not just syntactically, as McDermot implied mischieveously on rdf-logic)). 

NOTE that in the definition of DAM+OIL+types it should be made clear that it is really 
- a language with two variants, both of which are legal, 
- one of which is computationally tractable
- both of which can be given a formal semantics (although we currently only have one for the seperated variant, I believe it should be possible do define a semantics for the mixed variant)
- and for any set of expressions it is easy to determine to which variant it belongs. 

[7] I think the only current open problem is the root of the class hierarchy. Clearly the mixed variety needs Thing to be the union of predefined and user-defined clases. Can the separated variety be made to work with this? (e.g by restricting its use in expressions?). 

Tell me where I'm being too optimistic.


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