Suggested changes to concrete datatypes proposal

From: Jeff Heflin (heflin@cs.umd.edu)
Date: 01/29/01


Ian and Peter's concrete datatypes proposal [1] prompted a great deal of
discussion on RDF Logic and last week's telecon. Although I think that
in general the proposal is very good, I have expressed a feeling that
some of the additional syntax was unnecessary (see RDF logic for
background of the discussion). Here, I move that Ian and Peter's
proposal for concrete datatypes be accepted, but with with the following
changes to simplify syntax:

1) add a class called daml:Type

2) both rdfs:Class and daml:DataType are subClassOf daml:Type

3) remove daml:onConcreteProperty and change the range of
daml:onProperty to rdfs:Property

4) replace daml:toClass and daml:toDataType with daml:toType, which has
domain daml:Restriction and range daml:Type

5) remove daml:hasDataValue (use daml:hasValue for both class and
datatype values)

6) replace daml:hasClass and daml:hasDataType with daml:hasType, which
has domain daml:Restriction and range daml:Type

7) replace daml:hasClassQ and daml:hasDataTypeQ with daml:hasTypeQ,
which has domain daml:Restriction and range daml:Type

8) for DAML purposes, rdfs:range will have range daml:Type (so we can
express ranges using data types)

9) change the type of daml:onProperty to daml:UniqueProperty (so that a
daml:Restriction can have at most one daml:onProperty, disallowing the
odd semantics that occur when someone tries to define multiple
restrictions within a single <Restriction> element).

As I see it, the advantages of this proposal are:

1) users don't need to learn separate syntaxes to express restrictions
for concrete properties vs. abstract properties

2) when we extend the language with other semantic primitives, we don't
need to create distinct concrete domain primitives that correspond to
each abstract domain primitive

3) we still restrict what can be said about the concrete domain. For
example, you can't have a DataType as range of rdf:type (so users can't
specify new instances of a data type), as range of rdfs:domain (so no
property can have a data type as its domain), or as the domain and range
of rdfs:subClassOf (so no hierarchical relationships can be specified).

A possible disadvantage is that there may be properties for which it is
unknown whether they belong to the concrete or abstract domains (i.e.,
if the property is of type rdfs:Property (as opposed to AbstractProperty
or ConcreteProperty) and has no range or range that is daml:Type. It is
also possible that a property may specify ranges from both the abstract
and concrete domains. However, we could probably suggest reasonable
behaviours for each of the situations (e.g., a property is assumed to be
abstract unless otherwise specified, a property with ranges from both
domains is invalid).

Jeff

[1] http://www.cs.man.ac.uk/~horrocks/daml+oil/Datatypes/


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