Re: Suggested changes to concrete datatypes proposal

From: Jeff Heflin (
Date: 01/30/01

Ian Horrocks wrote:
> While I have some sympathy with Jeff's wish to simplify the syntax, I
> think there are some serious problems with his proposal (Peter has
> already pointed out some). Moreover, the simplification idea seems to
> be predicated on the assumption that people will be generating
> daml+oil using a text editor. I believe that, on the contrary, we
> should assume that only experts/masochists will work this way, and
> that everyone else will use more sophisticated tools. For such tools,
> the more complex syntax wont be a problem and may even be beneficial
> as it is more precise and easier to parse.

While I agree that tools might eventually hide syntax from ordinary
users, I don't think the Web community will get behind a language and
develop the tools for it if they find the language awkward and

> As far as tools are concerned, you are no doubt sick of hearing me
> tell you about OilEd, and I believe that both Protege and OntoEdit
> will/do support daml+oil. Any sane person should use such tools and
> let them worry about the syntax. If an expert wants to write daml+oil
> directly, they can do it, but we should assume that they are able to
> look after themselves. Experts may even want to write something like:
> <daml:Restriction>
>    <daml:onProperty rdf:resource="#hasChild" />
>    <daml:hasClass rdf:resource="#tall">
>    <daml:onProperty rdf:resource="#hasParent" />
>    <daml:hasClass rdf:resource="#short">
> </daml:Restriction>
> as it is much more compact than the expanded intersection of
> restrictions (experts are like that).

I'm afraid I don't quite get this example. Didn't we determine that the
semantics would say that this restriction is something that "has a child
who is tall and short and a parent that is is tall and short," which
assuming tall and short have their traditional definitions is the empty
set? If we are to interpret this as "has a tall child and a short
parent", then we need to be able to preserve the ordering of the
properties on the Restriction, which the RDF graph model doesn't do.

> The proposal also breaks the separation between concrete and abstract
> domains because we can have things like:
> <daml:complementOf>
>   <daml:Restriction>
>      <daml:onProperty rdf:resource="#hasHeight" />
>      <daml:toType rdf:resource="#tall">
>   </daml:Restriction>
> </daml:complementOf>
> which states describes the class of objects that have a height that is
> either an instance of the abstract class "tall" or a concrete data
> value. It was to avoid this problem that the separation of concrete
> and abstract properties was introduced.

If hasHeight had a range defined, then this problem would be avoided. If
not, then you are correct. However, I think if we specified that certain
troublesome constructs like this were undefined, then DL systems could
simply ignore things that would give them trouble.

> I have also added a few comments below.

I have also replied to a few comments below.

> Regards, Ian
> On January 29, Jeff Heflin writes:
> > 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
> There could be instances of daml:Type that are neither rdfs:Classes
> nor daml:DataTypes. This is a problem when using daml:Type as a range
> restriction.

I mention this in my paragraph about disadvantages, where I suggest that
we could specify that such situations default to being in the abstract
domain or are undefined (our choice).

> > 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)
> In other words, you need to break/change RDFS for this to work.

In your original concrete datatype proposal, data types can't be used as
ranges; in order to do so would require the same change. I was just
trying to fix what I saw as an ommission. Beside, breaking/changing RDF
hasn't stopped us before ;-)

> > 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).
> I am very much opposed to using daml+oil constructs to apparently
> specify/constrain the language itself as daml+oil does not in general
> confer any semantics on such usages.

I don't quite understand your aprehension here. If I had used
daml:cardinality=1 (which requires a daml:Restriction and
daml:onProperty to be specified) then I could see problems with the
circularity of the definition. That's why I chose to make it a
daml:UniqueProperty, which is really just a form of bootstrapping the

> > 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
> See my opening remarks - users don't need to learn any syntax, they
> just need to use a suitable tool.
> > 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
> This is a hassle for us, but shouldn't worry users of suitable tools.
> > 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]

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