Re: Suggested changes to concrete datatypes proposal

From: Peter F. Patel-Schneider (
Date: 01/30/01

There are three ways of looking at concrete objects and their intertwining
with abstract objects.

1/ One domain, no separation

	Concrete objects act just like abstract objects.  They can be the
	subject of properties, new classes of concrete objects can be
	defined, etc., etc.

	This view has untenable computational problems, both theoretical
	and practical.  On the theoretical side, reasoning become
	undecidable.  On the practial side, mechanisms have to be provided
	to give concrete objects properties, etc., etc.

2/ Two separate domains

        Concrete and abstract objects form completely separate domains, and
        no semantic mapping can map to their union.  Concrete objects
        cannot participate in abstract properties at all.  Concrete objects
        can only participate as the target of concrete properties.
        Concrete properties cannot have inverses, and cannot be

	This view has the easiest implementation.  However, the strict
	separation requires that modellers make the abstract/concrete
	distinction for all properties.

3/ One domain, strong separation

	There is a single domain for concrete and abstract objects, with
	two subdomains.  Some semantic mappings map to this domain.
	However, most semantic mappings map to one of the subdomains.
	Complement is relative to the abstract subdomain only.

	This view is more flexible.  However, the possibility of properties
	that map to the full domain means that implementers and modellers
	cannot count on property targets being from the same domain.  As
	many semantic mappings are applicable only to the abstract domain,
	programs will have to check for the appropriate domain.  

	This view has to be carefully constructed so that it does not
	degenerate into the first view.  For example, there still needs to
	be two types of properties, namely general and abstract
	properties.  Only abstract properties can have inverses, etc.,
	etc.  This view also has the most changes from RDF(S).

Here is one *possible* skeleton for the third view.  I have not analyzed
this extensively, so there is the distinct chance of problems herein.

daml:Thing				the entire domain
rdfs:Literal <= daml:Thing		the concrete subdomain
					this requires a union type for all
					concrete types
rdfs:Resource <= daml:Thing		the abstract subdomain ?

rdfs:Class				the class of all classes
					note that concrete datatypes are 
					now classes (I think)

daml:AbstractClass			the class of all abstract classes
daml:ConcreteClass			the class of all concrete classes

	rdfs:domain = rdfs:Resource
	rdfs:range = rdfs:Thing

	rdfs:range = rdfs:Resource 	this requires the change to rdfs:range

	rdfs:range = rdfs:Literal 	this requires the change to rdfs:range

daml:disjoint				these can only involve abstract classes

	rdfs:domain = daml:AbstractClass
	rdfs:range  = daml:AbstractClass

	rdfs:domain = daml:AbstractClass
	rdfs:range  = daml:AbstractClass

daml:Restriction <= daml:AbstractClass

	rdfs:domain = daml:Restriction
	rdfs:range  = rdfs:Property

	rdfs:domain = daml:Restriction
	rdfs:range  = rdfs:Class

	rdfs:domain = daml:Restriction
	rdfs:range  = daml:Thing

	rdfs:domain = daml:Restriction
	rdfs:range  = rdfs:Class

	rdfs:domain = daml:Restriction
	rdfs:range  = rdfs:Class

	rdfs:domain = daml:Restriction
	rdfs:range = >=0

	rdfs:domain = daml:Restriction
	rdfs:range = >=0

	rdfs:domain = daml:Restriction
	rdfs:range = >=0

	rdfs:domain = daml:Restriction
	rdfs:range = >=0

	rdfs:domain = daml:Restriction
	rdfs:range = >=0

	rdfs:domain = daml:Restriction
	rdfs:range = >=0

This archive was generated by hypermail 2.1.4 : 04/02/02 EST