From: Peter F. Patel-Schneider ([email protected])
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
unambiguous.
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
rdf:Property
rdfs:domain = rdfs:Resource
rdfs:range = rdfs:Thing
daml:AbstractProperty
rdfs:range = rdfs:Resource this requires the change to rdfs:range
daml:ConcreteProperty
rdfs:range = rdfs:Literal this requires the change to rdfs:range
daml:disjoint these can only involve abstract classes
daml:unionOf
daml:disjointUnionOf
daml:intersectionOf
daml:disjointWith
rdfs:domain = daml:AbstractClass
rdfs:range = daml:AbstractClass
daml:complementOf
rdfs:domain = daml:AbstractClass
rdfs:range = daml:AbstractClass
daml:Restriction <= daml:AbstractClass
daml:onProperty
rdfs:domain = daml:Restriction
rdfs:range = rdfs:Property
daml:toType
rdfs:domain = daml:Restriction
rdfs:range = rdfs:Class
daml:hasValue
rdfs:domain = daml:Restriction
rdfs:range = daml:Thing
daml:hasType
rdfs:domain = daml:Restriction
rdfs:range = rdfs:Class
daml:hasTypeQ
rdfs:domain = daml:Restriction
rdfs:range = rdfs:Class
daml:minCardinality
rdfs:domain = daml:Restriction
rdfs:range = >=0
daml:maxCardinality
rdfs:domain = daml:Restriction
rdfs:range = >=0
daml:cardinality
rdfs:domain = daml:Restriction
rdfs:range = >=0
daml:minCardinalityQ
rdfs:domain = daml:Restriction
rdfs:range = >=0
daml:maxCardinalityQ
rdfs:domain = daml:Restriction
rdfs:range = >=0
daml:cardinalityQ
rdfs:domain = daml:Restriction
rdfs:range = >=0
This archive was generated by hypermail 2.1.4 : 04/02/02 EST