From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 01/30/01
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.
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).
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.
I have also added 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.
> 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.
> 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.
> 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] http://www.cs.man.ac.uk/~horrocks/daml+oil/Datatypes/
This archive was generated by hypermail 2.1.4 : 04/02/02 EST