From: Dan Connolly (connolly@w3.org)
Date: 02/01/01
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. 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. 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? | 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. 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? -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ office: tel:+1-913-491-0501 pager: mailto:connolly.pager@w3.org (put return phone number in from/subject)
This archive was generated by hypermail 2.1.4 : 04/02/02 EST