- From: Deborah Mcguinness <dlm@ksl.stanford.edu>
- Date: Sat, 03 Feb 2001 13:07:38 -0800
- To: Tim Berners-Lee <timbl@w3.org>
- CC: RDF Logic list <www-rdf-logic@w3.org>, Ian Horrocks <horrocks@cs.man.ac.uk>
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