From: Dan Connolly ([email protected])
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:[email protected]
(put return phone number in from/subject)
This archive was generated by hypermail 2.1.4 : 04/02/02 EST