From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 02/01/01
On February 1, Dan Connolly writes: > In > http://www.cs.man.ac.uk/~horrocks/daml+oil/Datatypes/ > 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 domain. > 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 > http://www.w3.org/TR/query-algebra/#sec_operators_fns > > 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 http://www.w3.org/TR/NOTE-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 impossible. > | 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. Ian
This archive was generated by hypermail 2.1.4 : 04/02/02 EST