Re: DAML+OIL (March 2001) released

> > The idea behind DAML+OIL (March 2001) is to extend DAML+OIL
> > (December 2000) with arbitrary datatypes from the XML Schema type
> > system (http://www.w3.org/TR/xmlschema-2/#typesystem), while still
> > retaining the desirable properties of the ontology language, in
> > particular its (relative) simplicity and its well defined semantics.
>
>That is OK.
>
>
> > This is achieved by maintaining a clear separation between instances
> > of "object" classes (those defined using our ontology language) and
> > instances of datatypes (defined using the XML Schema type
> > system). In particular, it is assumed that the domain of
> > interpretation of object classes is disjoint from the domain of
> > interpretation of datatypes, so that an instance of an object class
> > (e.g., Leo the Lion) can never have the same interpretation as a
> > value of a datatype (e.g., the integer 5), and that the set of
> > object properties (which map individuals to individuals) is disjoint
> > from the set of datatype properties (which map individuals to
> > datatype values).
>
>This solution is not in the spirit of RDF.

Perhaps not, but that was not the primary goal of everyone on the 
committee. DAML+OIL is RDF-compliant (for political rather than 
technical reasons), but do not make the error of thinking of it as 
simply an extension to RDF.  DAML+OIL was constructed by a committee 
with members who have a variety of agendas, and taking RDF seriously 
was of central importance only to a minority. In particular, being 
what might be called RDF-politically correct is not of central 
importance to me personally, since in my view RDF is based on a 
fundamentally flawed semantic model and is not viable for long-term 
use as a representation language.

> Of course the resources is
>disjoint from the actual literals.  And that goes also for how to
>validate them.
>
>* The datatype tells something about the content of a literal.
>
>* The schema tells something about the properties of a resource.
>
>There is no need to split up the rdfs:Class or rdfs:Property.  RDFS
>already has this distinction in the rdfs:Literal class.
>
>Datatype properties are recognised by having Datatype as range.
>Datatype is recognised by being subClassOf rdfs:Literal.
>
>
>The classes daml:ObjectProperty, daml:DatatypeProperty and daml:Class
>should go away.
>
>I can see that the property classes are a result from the need to
>declare that we are pointing into the XML Schema domain.  And
>daml:Class is used for asserting that daml will not be used for doing
>logic with the datatypes.
>
>
>You can't isolate DAML from the rest of the world.

On the other hand, you shouldn't make the mistake of thinking that 
the rest of the world consists of nobody but RDF enthusiasts. At the 
very least, there are the Topic Mappers to contend with.

> What about the
>next expansion?  Will DAML subclass more RDFS classes and properties,
>just to make certain that it can not be used with anything except
>itself?  Why should we not be able to use DAML for adding cardinality
>information to a class defined in a non-DAML schema?
>
>
>We must be able to represent the datatypes in the RDF graph.

RDF graphs are just one data structure convention among many others 
in use around the world, and for many purposes they are not even the 
best.  The basic simplicity of the 'triples' model is often cited, 
but the fact that arbitrarily complex graphs (and hence arbitrarily 
complex syntactic constructs) can be encoded in triples has been 
widely known since the 1880s (CS Peirce wrote extensively on the 
subject) and has been a commonplace observation in data structuring 
since the early 1960s; so the enthusiasm for this supposed 
universality seems to reflect ignorance rather than insight. RDF 
triples have no special syntactic advantages over, say, LISP 
Sexpressions, and they provide no special functionality or semantic 
power. The RDF documentation and discussion archives are rife with 
elementary errors (such as confusing use and mention, confusing 
syntactic structure with meta-description, confusing asserting with 
reference, confusing names with URIs, and confusing dereferencing 
with denotation) that they often border on being simply incompetent. 
All the RDF engines I am aware of provide only primitive 
data-structuring abilities and have a level of sophistication in 
inferencing which is best described as pathetic.
...

>Why the need to encapsulate DAML?  This is the same thing as with all
>those imported terms from RDF/RDFS.  Thats not the way to do it.  Were
>you planning to introduce XML schema datatypes to RDF, but *only* for
>those using DAML?

We were defining DAML+OIL, not extending RDF. Part of the reason for 
keeping DAML classes separate from RDF classes (and so on) was 
precisely to enable us to give DAML structures a precise semantic 
meaning. There is no precise semantics available for RDF, and all the 
imprecise attempts at a semantic description seem to be confused or 
broken in some way; and we have no mandate to declare a precise 
semantics for RDF structures in any case.

>The datatypes should be in a separate schema.  It should be a simple
>mapping to the xmlschema typesystem.  The logic lies in the xmlschema
>spec.
>
>
> >   3. The semantic integrity of the language is not compromised;
> >   defining theories for all the XML Schema datatypes would be
> >   difficult or impossible without extending the language in
> >   directions whose semantics may be difficult to capture in the
> >   existing framework.
>
>What existing framework?  Treat DAML as a confined language if you
>must.  But DAML and xmlschema should both be part of the bigger RDF
>network.

That is a political claim, not a technical one, and one that I would 
strongly oppose. RDF has created far more problems for DAML+OIL than 
it has been of utility.  The quote refers to difficulties of 
capturing semantics: right now, RDF has no semantics, and until it 
gets one, being part of the " bigger RDF network"  simply endorses 
confusion.

Pat Hayes

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Friday, 30 March 2001 14:27:31 UTC