Re: on disjointness motivation

From: Ian Horrocks (
Date: 02/01/01

On February 1, Dan Connolly writes:
> In
>  Sun, 21 Jan 2001 23:09:32 GMT
> |The disjointness of abstract and concrete domains is motivated by both
> |philosophical and pragmatic considerations: 
> |
> |   1.Concrete data types are considered to be already
> |     sufficiently structured by the built-in predicates;
> |     therefore, it is not appropriate to form new classes
> |     of concrete values using the ontology language.
> That's the first occurence of built-in predicates; I'm
> note sure what you mean by it. If you mean that "the XML
> schema datatypes spec specifies everything we need to
> know" about, for example, integers, then I disagree.

A built in predicate is something like "minInclusive" in XML schema.

The proposal does not claim to be the one true path, or to be a
"universal web language" that allows us to specify "everything we need
to know" about concrete datatypes or about anything else. What the
proposal describes is one way to integrate concrete types with
daml+oil such that the resulting system has some useful properties.

> Much of what I want to use DAML/RDF for is to express, formally,
> things that are expressed informally in various W3C/IETF/etc.
> specifications. The domain of discourse in these ontologies
> will be mostly strings and integers and bytes and
> byte sequences and such.
> |   2.The simplicity and compactness of the ontology language are not
> |     compromised; even enumerating all the XML Schema data types would
> |     add greatly to its complexity, while adding a theory for each data
> type,
> |     even if it were possible, would lead to a language of monumental
> |     proportions. 
> Making concrete types disjoint from abstract types does not 
> compromise the simplicity of the language? I disagree.
> As to compactness... the specification for how floats
> and dates work has to be somewhere. I'd prefer to
> re-express it formally in RDF, but even if we don't
> do that, you can't pretend that DAML+OIL+concrete
> doesn't includes a specification for floats
> and dates and such, if only by reference to some
> widely-reviewed english prose.

One of the key features of the proposal is that it doesn't care about
any of this stuff - that is left up to the type system. From the point
of view of the abstract language, concrete datatypes and values are
simply treated as atoms: all we know about them is that they are
interpreted respectively as subsets and elements of the concrete

> Meanwhile, W3C is engaged in formalizing much of this
> stuff already. See, for example, the XML Query algebra stuff:
>   5.6 Operators and built-in functions
> The notation they use doesn't (yet!) ground its terms in URI space,
> but if I can convince them to do that, we can convert their
> formalism to our notation by machine.
> We can also convert XML Schema syntax for minExclusive
> and such to DAML by machine, by the way. I wish the
> XML Schema WG had chosen to use RDF in the first
> place (ala DCD, but
> oh well... we can do a post-hoc translation, as
> long as enough of the relevant terms have URIs.
> Note that the XML Schema spec does separate
> the concrete syntax from abstract "components" which
> has the same DLG/subject-property-object structure
> as the RDF model (or, as I'm starting to say:
> the RDF abstract syntax).
> |   3.The semantic integrity of the language is not compromised;
> defining
> |     theories for all the XML Schema data types would be difficult or
> impossible
> |     without extending the language in directions whose semantics may
> be
> |     difficult to capture in the existing framework. 
> I don't understand this. What do you mean by "the existing framework"?
> We have two forms of semantics: KIF axioms and a model-theoretic
> semantics. Specifying how integers, dates, and floats work
> in KIF has been done many times, no? And the model-theoretic
> semantics is just using ZF set theory; again, saying how
> floats and dates and such work in ZF set theory has been
> done many times.
> Where's the "difficult or impossible" part?

Specifying the semantics of concrete datatypes using some arbitrary
formalism doesn't help us that much. What would help us (at least in
theory) would be to use our existing daml+oil language to describe the
properties of concrete datatypes. This would be difficult or

> |   4.The "implementatibility" of the language is not compromised;
> |   applications (including reasoners) can simply exploit the
> |   services of XML Schema type checker/validater (assuming that
> |   such a component exists, or soon will exist). 
> Yes, a reasoner that was complete over the October and December
> drafts won't necessarily be complete over a language with,
> for example, integer arithmetic in it. But that doesn't mean
> such reasoners become useless; they just become incomplete.
> Sometimes they'll return "that's not a theorem I know how
> to prove." But when/if they recognize a problem as something they
> *can* proove, the resulting proof can be checked
> in an interoperable way.

Excellent. I can provide you immediately with a highly efficient
reasoning engine that completely satisfies your requirements:

(defun UWL-reasoner (theorem)
  (format nil "that's not a theorem I know how to prove"))

Seriously, completeness isn't the only issue. The proposal is intended
to allow for existing reasoners to be extended in a way that maintains
all of their existing properties, including efficiency. 

> Hmm... is it feasible to make it easy for such reasoners
> to recognize the problems they know how to solve without
> fragmenting the domain of discourse? I think I've
> seen some mail fly by to that effect; i.e. to facilitate
> the use of reasoners that can exploit disjointedness,
> we could specify disjoint classes daml:Abstract and daml:Concrete
> (and specify their relationships to the date, string,
> etc. classes and the rdfs:Literal class) and allow
> ontology designers that want to use oiled-style
> reasoners to partition their classes under
> daml:Abstract and daml:Concrete.
> Then oiled could grab the input and bail out if
> it (heuristically) finds any classes that aren't
> specified to be subclasses of daml:Abstract nor daml:Concrete.
> Would that work? i.e. could oiled internally maintain
> duals of properties like hasClass/hasClassQ without the
> necessity for ontology desingers choose between them?

This is more or less in line with our proposal. We specify a language
such that if you stay within it we can guarantee certain properties
(i.e., tools will work). It isn't forbidden to go outside the language,
but you do so at your own risk (i.e., tools may not work).

There is nothing to say that some future language extension wont
produce a specification for some less restrictive language with its
own (presumably weaker) properties.


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