Re: DAMl "Thing" should be Top, Universal class - including concrete types

There has been some discussion concerning the proposed separation of concrete
domains from that of Daml:Thing (abstract domains).
In a separate phone discussion, I mentioned that I have worked with a
knowledge representation and reasoning system --CLASSIC --
http://www.bell-labs.com/project/classic/ , for many years that included this
separation.  In CLASSIC, there was a class called CLASSIC-THING which was
disjoint from a class called HOST-THING.  Both CLASSIC-THING and HOST-THING
were subclasses of a top concept called THING.  CLASSIC-THING and HOST-THING
were disjoint.  HOST-THING included terms defined in the host language (lisp,
c, or c++ in this case) and included things such as numbers, strings, etc.

I have helped people use CLASSIC in a series of large applications; the
largest and longest lived was a family of configurators called PROSE/QUESTAR
[1].  This included 17 configurators, some of which were used for a decade.
They were used by AT&T and Lucent.  Other major application areas include data
archeology  [2], software discovery [3], query expansion [4], query answering
[5], plan representation [6],  knowledge based software engineering [7], and
other domains.   We also spent time considering the usability issues of the
language [8,9].
The reason for all of the citations and the list, is to support the claim that
at least in one case of use over a long time (a decade) in a wide variety of
application areas, a large number of application developers have not found the
separation of concrete and abstract domains to have been problematic in
application development and deployment.   It was many times the case in these
application areas, that I was the main contact for the research group when
users had difficulty in conceptual modeling.  I did not experience a problem
with this issue.  My claim is that I would have the best chance of all those
associated with CLASSIC, of hearing of the problems that users encountered due
to this design decision.

There were two examples given in either verbal or online discussion of this
issue that I found interesting as possible motivations from an empirical
perspective for classes including both concrete and abstract domains.  Tim
Berners-Lee mentions the possibility of book titles being either strings or
complex objects.  One modeling solution to that problem is to have book titles
always be complex objects, one or more components of which is a string for
encoding the title.  Of course, from a usability perspective, some users might
not like that solution, but I think it is workable.
Pat Hayes also suggested an example of possibly wanting to add properties to a
number.  For example, say one wanted to annotate the number 232 as the number
of employees in a particular company.  While this would be precluded in the
current concrete domains proposal by Horrocks and Patel-Schneider, one could
of course store on the particular company the number of employees, and then
retrieve that information by looking for the number of employees of the
particular company.
I would posit that we have not yet seen a compelling naturally occurring
example of a need for combination of the types.

I am not saying by this posting that it is not desirable to allow more breadth
in a design that allows classes to contain both abstract and concrete
objects.  I am also not claiming that we can ever anticipate all of the needs
of our users.
 I am just attempting to provide what I think is a fairly substantial piece of
empirical evidence that at least one knowledge representation system has been
used in a wide variety of application domains for a decade without running
into insurmountable conceptual modeling problems caused by the limitation of
separating concrete from abstract domains.

Deborah McGuinness
dlm@ksl.stanford.edu


[1] Deborah L. McGuinness and Jon Wright. ``An Industrial Strength Description
Logic-based Configurator Platform''. IEEE Intelligent Systems, Vol. 13, No. 4,
July/August 1998, pp. 69-77. )

[2] Ronald J. Brachman, Peter G. Selfridge, Loren G. Terveen, Boris Altman,
Alex Borgida, Fern Halper, Thomas Kirk, Alan Lazar, Deborah L. McGuinness,
Lori Alperin Resnick. ``Integrated Support for Data Archaeology.'' In
International Journal of Intelligent and Cooperative Information Systems, 2:2
1993, pages 159--185.

[3] P. Devanbu, R.J. Brachman, P.G. Selfridge, B.W. Ballard: "LaSSIE: A
knowledge-based software information system" Communications of the ACM,
34(5):35--49, May 1991.

[4] Deborah L. McGuinness. ``Ontological Issues for Knowledge-Enhanced
Search''. In the Proceedings of Formal Ontology in Information Systems, June
1998. Also in Frontiers in Artificial Intelligence and Applications,
IOS-Press, Washington, DC, 1998.

[5] Alon Y. Levy, Anand Rajaraman and Joann J. Ordille, ``Query Answering
Algorithms for Information Agents'' Proceedings of the 13th National
Conference on Artificial Intelligence, AAAI-96, Portland, Oregon, August,
1996.

[6] P. Devanbu , D. Litman , CLASP - a plan representation and classification
scheme for a software information System,  Published in Artificial
Intelligence , 1996

[7] P. Devanbu , M. Jones , The use of description logics in KBSE systems.
Published in ACM Transactions on Software Engineering and Methodology , 1997

[8] Deborah L. McGuinness and Peter F. Patel-Schneider. ``Usability Issues in
Knowledge Representation Systems''. In Proceedings of the Fifteenth National
Conference on Artificial Intelligence, Madison, Wisconsin, July, 1998. This is
an updated version of ``Usability Issues in Description Logic Systems''
published in Proceedings of International Workshop on Description Logics, Gif
sur Yvette, (Paris), France, September, 1997.

[9] Ronald J. Brachman, Alex Borgida, Deborah L. McGuinness, and Peter F.
Patel-Schneider. "Reducing" CLASSIC to Practice: Knowledge Representation
Theory Meets Reality. In Artificial Intelligence 114(1-2) pages 203-237,
October


Tim Berners-Lee wrote:

> I am concerned about the suggestions that what DAML
> calls a daml:Thing, and RDF (unfortunately) a rdf:Resource
> should not include concrete types.
>
> I feel RDF should be fixed so that literal strings are regarded
> as particular resources, and I think even a mapping into URI space
> should be specified using the "data:" scheme which has been defined
> exactly for this purpose.  (<data:logic/rdf;10> = "10")
>
> But the main point of this email is to counter suggestions that
> concreete types and abstract types should be made quite distinct
> and properties only be allowed to hve a range and domain
> which are subclasses of one or the other.
>
> The basic fundamental raeson why this is bad is that it is not minimalist
> design.  It is fine for an individual project, but for the semnatic web
> it can't be an assumption you force in theunderlying infrastructure.
> Essentially this says, "All things, whatever they are are one of two
> distinct classes, at a more fundamental level than any other
> distinction".  This sort of statement must only be made when it
> is absolutely necessary to create an infrastructure which will stand up
> on its own feet.
>
> It is more difficult to give examples which will appeal to an arbitrary
> reader
> as to why one might need properties whose range or domain contain both
> abstract and concrete types.
>
> One example is the title of a book.  The property foo:title, say related
> an abstract work and something which is a human-oriented description
> of it.  A simple use is to say
>
> title(mybook, "The cat in the hat")
>
> A more complicated use is to say
>
> title(mybook, mybooktitle)
> english(mybooktitle, "The cat in the hat")
> french(mybooktitle, "Le chat dans le chapeau")   %%  or whatever
>
> Annother is that I might genericly want to write logic to deal with the
> values of fields in an address book.  I might want to talk about the
> validity and caretion date and author of fields and their
> values, when some values are concrete (date of birth, an xmldt:date)
> and some are complex (office, a location, which has properties
> such as address and phone number and so on).
>
> I actually find the idea so odd that I find it difficult to explain why it
> is
> weird.  It shows how different woldviews can be, I suppose. I hope this
> makes sense.
>
> If the logic is set up so that there is no set which includes both leaves
> and branches, we have an arbitrary constraint underpinning all our
> work, and I find that unacceptable.  Unless I have missed something.
>
> Tim

--
 Deborah L. McGuinness
 Knowledge Systems Laboratory
 Gates Computer Science Building, 2A Room 241
 Stanford University, Stanford, CA 94305-9020
 email: dlm@ksl.stanford.edu
 URL: http://ksl.stanford.edu/people/dlm/index.html
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801 705
0941

Received on Saturday, 3 February 2001 16:07:41 UTC