Re: DAML+OIL (March 2001) released

Reply to http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0105.html


And now some comments on this text about the datatype extension:
        http://www.daml.org/2001/03/differences-daml+oil.html


> 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.  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.  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.  That
doesn't mean that all the datatypes should be included in the DAML
schema.  There is probably a difference between daml:unionOf and
xsd:union.  But that is not a problem.  Let XSD define it's xsd:union.
RDFS should probably not be used for the RDF representation of XSD,
since xsd isn't talking about resources.  The actual mapping to RDF is
trivial.  It will almost suffice to enclose the schema with a RDF tag.

The important thing here is to make { xsd:element rdfs:subClassOf
rdfs:Literal }.  That's the way to integrate XML schema into RDF.  No
need for alienating DAML or use those extra property types.



> The disjointness of object and datatype domains is motivated by both
> philosophical and pragmatic considerations:
> 
>   1. Datatypes are considered to be already sufficiently structured
>   by the built-in predicates; therefore, it is not appropriate to
>   form new classes of datatype values using the ontology language.

What built-in predicates?


>   2. The simplicity and compactness of the ontology language are not
>   compromised; even enumerating all the XML Schema datatypes would
>   add greatly to its complexity, while adding a theory for each
>   datatype, even if it were possible, would lead to a language of
>   monumental proportions.

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?

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.


>   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).

The soon to exist xmlschema validators can still be used.  We are just
talking about a RDF representation of the datatypes and it's
relationship to the Literal class.





The committee lists both Ora Lassila and Tim Berners-Lee.  How can it
be that they haven't objected to this new version?  We have discussed
this thing many times on the list in the past.  It seems like the
authors hasn't got the big picture here.


From "Issues Raised in the RDF Interest Group":
        http://www-uk.hpl.hp.com/people/bwm/rdf/issues.htm

  * Unifying Literals and Resources
  * Typing Literals
  * URI References/Mime-Types and Resources



Some of my previous thoughts:

 http://jonas.liljegren.org/perl/proj/rdf/schema_editor/letters/literals_2.txt

 http://jonas.liljegren.org/perl/proj/rdf/schema_editor/letters/literals_3.txt




-- 
/ Jonas Liljegren

The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/

Received on Thursday, 29 March 2001 04:55:34 UTC