From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 01/30/01
Peter, As you say, preventing 3 from degenerating into 1 is difficult. I think that what you have proposed below suffers from the problem I mentioned in my reply to Jeff. i.e., when you negate modal atoms you get an implicit union of abstract and concrete types. This is the reason for having separate concrete and abstract properties. Ian On January 30, Peter F. Patel-Schneider writes: > 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