From: Mike Dean (mdean@bbn.com)
Date: 02/20/01
In developing a new ontology for high-level project plans
(using OilEd) today, I ran into 2 issues related to our
current discussions regarding abstract classes and concrete
datatypes.
1) I wanted to add a "collaborator" property to the class
Task, which could refer to either a specific Project
instance known to me or a string representing a more fuzzy
entity such as "various experts, as needed". The
alternatives (2 separate properties, defining FuzzyProject
as a subclass of Project, etc.) to use of an
abstract/concrete union type seemed less desirable.
2) I wanted to associate dates with Deliverable, but need to
label different dates (e.g. alpha, beta, and final for
Software). I defined a Date class with properties
descriptor (currently a string) and date (an XML Schema
date). It was most natural to also use the date property to
associate the Date with the Deliverable. This won't work if
the date property has to be either concrete or abstract.
Slightly new topic: I got to look at the latest
DAML+OIL+CONCRETE proposal [1] as somewhat of an outsider,
since I wasn't able to participate in the Language breakout
at the PI Meeting. I gather that consensus was reached (a
good thing). However, I fear that we've gone full circle,
and created a baroque compromise. I've got 2 major
concerns:
1) ConcreteProperty definitions containing range
restrictions seem like a step backward. In the early stages
of DAML+OIL, folks convinced me and others that the RDF
property range constraint was too "constraining" and that we
should adopt the OIL notion of declaring properties just as
names and employing restrictions on class/property pairs (to
allow reuse of properties such as color in different
classes, etc.). It seems to me that there are several
levels at which we might be able to enforce the
concrete/abstract dichotomy:
AbstractProperty vs. ConcreteProperty
AbstractRestriction vs. ConcreteRestriction
hasClass vs. hasDataType
I'd prefer the lowest possible of these levels, and that we
be able to support at least unconstrained properties that
can take on any value. We touched on this a bit during our
last telecon.
(I also now have similar reservations about UniqueProperty,
UnambiguousProperty, and probably TransitiveProperty -- that
these attributes should instead be specified for
class/property pairs -- e.g. a socialSecurityNumber
unambiguously identifies a Person but not a BankAccount).
2) I think any language that requires coding like
<shoesize>
<xsd:decimal rdf:value="14"/>
</shoesize>
rather than
<shoesize>14</shoesize>
will be a very hard sell. Will all the instances have to
change if the ontology evolves to use a float instead? XML
documents using XML Schema don't require this. What's the
internal representation for tools like RDF API that produce
triples? What if the ontology says xsd:int and the instance
says xsd:short? What happens if I use mysd:shoeSize rather
than xsd:decimal?
I think we're going to a whole lot of trouble to accommodate
a specific class of tools that want to convert data types
during lexical analysis (vs. a later phase) without having
previously read in the ontology. I'd prefer to stay closer
to RDF and adopt a simpler set of constructs that optionally
constrain Literal property values to be strings in the
lexical space of a specified XML Schema datatype.
Am I now the odd man out on the Committee? I do appreciate
everyone's hard work in this area, and apologize if I'm
ruffling feathers.
Mike
[1] http://www.cs.man.ac.uk/~horrocks/DAML+OIL/Datatypes/
This archive was generated by hypermail 2.1.4 : 04/02/02 EST