From: pat hayes ([email protected])
Date: 03/21/01
Let me amplify my concerns about the use of the 'abstract'
terminology, and suggest an alternative that would avoid them. I'm
sorry if this is being raised rather late in the day, but I was under
the impression that we had in fact decided to not use this 'abstract
class' terminology in a telecon a while ago.
Throughout the English-speaking world, and especially in what might
be called 'ontologically savvy' people, the term 'abstract' has a
very clear meaning, which is often contrasted with 'physical' or
'concrete'; which is that something is 'abstract' if it doesn't have
a physical presence. For example, numbers and properties might be
called abstract, while things like animals and automobiles are
definitely not abstract: one can see them, hit them, drill holes in
them, etc.. This means that the usage of abstract/concrete in the
DAML documentation is seriously out of line with normal usage; and
this is particularly unfortunate when the things it is talking about
- classes and their contents - are precisely the kinds of thing that
people use this vocabulary to describe. Many people would say that
classes are always abstract, for example (not in the DAML sense), so
that to call Animal an abstract class is acceptable, but a bit odd -
rather like calling someone a human person - but to say that animals
are abstract is a mistake, and to say that animals are abstract but
integers are concrete is completely insane. So by using this
terminology in this way we are creating a barrier to comprehension
and a big source of potential confusion, and really for no good
reason.
The solution is very simple: don't refer to 'abstract
objects/classes' at all, just to 'objects/classes'. All we need to do
to distinguish 'concrete types' - we should also avoid that usage -
is to refer to them as what they in fact are, ie values that belong
to XML Schema datatypes, and we can use 'datatype values' for short,
and to say vividly and clearly that datatypes are not, and cannot be,
DAML classes, and that datatype values are not, and cannot be,
contained in any DAML class. Then we can just translate the current
terminology as follows:
abstract class --> class (or --> DAML class , if the point needs
emphasising)
abstract object --> object
abstract domain --> class domain (or --> DAML class domain)
concrete class --> datatype (or --> xmls datatype)
concrete object --> datatype value
I could revise the documentation in the next day or 2 to reflect
these changes (and remain grammatical) if people agree that it should
be done.
Comments??
Pat Hayes
PS. For example, the following section of the reference manual would
translate as shown below:
------
Abstract Objects and Datatype Values
DAML+OIL divides the universe into two parts. One part consists of
the values that belong to XML Schema datatypes. This part is called
the datatype
domain. The other part consists of objects that are created within
DAML+OIL (or RDF). This part is called the abstract domain.
DAML+OIL is mostly concerned with the creation of classes that
describe (or define) part of the abstract domain. Such classes are
called abstract classes and
are elements of daml:Class, a subclass of rdfs:Class. DAML+OIL (March
2001) also allows the use of XML Schema datatypes to describe (or
define)
part of the datatype domain. These datatypes are used within DAML+OIL
simply by including their URIs within a DAML+OIL ontology. They are
(implicitly) elements of daml:Datatype.
-------
Objects and Datatype Values
DAML+OIL divides the universe into two parts. One part consists of
the values that belong to XML Schema datatypes. This part is called
the datatype
domain. The other part consists of objects that are created within
DAML+OIL (or RDF). This part is called the class domain.
DAML+OIL is mostly concerned with the creation of classes that
describe (or define) part of the class domain. Such classes
are elements of daml:Class, a subclass of rdfs:Class. DAML+OIL (March
2001) also allows the use of XML Schema datatypes to describe (or
define)
part of the datatype domain. These datatypes are used within DAML+OIL
simply by including their URIs within a DAML+OIL ontology. They are
(implicitly) elements of daml:Datatype.
-------
---------------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola, FL 32501 (850)202 4440 fax
[email protected]
http://www.coginst.uwf.edu/~phayes
This archive was generated by hypermail 2.1.4 : 04/02/02 EST