From: pat hayes (phayes@ai.uwf.edu)
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 phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
This archive was generated by hypermail 2.1.4 : 04/02/02 EST