From: Deborah McGuinness (dlm@ksl.stanford.edu)
Date: 05/07/01
Thanks for the input. I will solicit input in the call tomorrow but also expect
that there may be shortish answers to 2 points and a long discussion on the other
point.
1 - Frame look and feel - I think there has been consensus that there should be a
presentation syntax. We are lacking a proposal for one or more however.
I would support Dieter's position that a frame-based look and feel syntax would be
of value for the language in terms of making it easier to use and I also believe
that it was one of the goals of the ontology language for the DAML program.
I think the action item is for a strawman proposal syntax to be generated.
3 - Name - My belief is that it has always been expected that the name would
change once the W3C ontology language committee formed. Even before the W3C
committee was expected, I think it was a common belief that the name would change
if the language took off. That in fact was one reason we did not work too hard on
the language name when we first announced DAML+OIL.
Given the expected committee formation, I would propose that we time the name
change with the committee formation but if people have name suggestions, I am
willing to be a collector of proposed names.
I will keep a list with
proposed name name suggestor name rationalization (if one is given)
2 - Layers - I left this for last since I think this is the longer discussion. My
belief is that everyone believes layers are good but coming up with the distinct
layers generates long discussions.
Stefan had made the most recent proposal for an inner layer.
We might decide on a strategy for choosing what goes in the more core layers.
choosing criteria may be:
a. tractability of inference (this was one issue that raised a long
discussion with stefan's proposal)
b. epistemological adequacy - thus do we have the expected needed
constructors from a
representational perspective
c. usability - may be different from b since although a user may be able to
say something with an
epistemologically adequate language, it may be awkward or obtuse and thus
users may need more
...
One proposed goal is to satisfy both a (possibly with some kind of average case
analysis)
and b to some justifiable level
and handle c with a front end interface.
I think the committee is in agreement that a layered approach is good and since
the last proposal on the table was stefan's, we are waiting for a revised version
of that to discuss.
Peter had volunteered to review it for point a above and I agreed to review it for
b at least from the perspective of usage I saw in a decade of classic usage and
also the usage that I saw in the usage of the frame-based systems at Stanford for
the last 2 years.
A review from other people on point b who have other perspectives would be useful
as well.
Dieter - if you would like to propose additional action or discussion, we would be
happy to take a proposal.
thx,
Deborah
Dieter Fensel wrote:
> Hi all,
>
> I will not be able to make it for the phone conference, however, I would
> like to input three major issues concerning DAML+OIL I have (based on
> various discussions at WWW10).
>
> 1. Frame-based look and feel
>
> One of the major design decision in OIL was to make it look frame-like.
> Frames offer a modeling paradigm that helps user to write knowledge
> models and that helps tool builder in coming up with nice interfaces.
> This idea seems to got lost in the DAML+OIL transformation.
>
> 2. Layered Language Architecture
>
> In OIL, we had the idea of a layered language architecture. This has
> several advantages:
>
> - Applications and tools do not need to support the full-fledged
> language in cases it is an over-kill.
> - By proper upwards-compartibility, tools at the lower level
> understand at least parts of the knowledge models from higher
> levels.
> - You have well-defined names and definitions for sub-languages.
>
> Stefan raised this point earlier and I would recommend to go for it in
> DAML+OIL, too. Otherwise you either will make tool development
> very difficult or you end up with a bunch of tools that each support
> different (and not very well-defined) subsets of the language. By giving
> subsets a name, a clear definition, and an inclusion order you may
> end up in a much better world.
>
> Even in case a sublanguage may have from a logical point of view
> the same expressiveness this still makes much sense. Two languages
> that may look the same for reasoning support tools may look
> very different for editors when the syntax of one is simplified.
>
> 3. The name "D"AML+OIL
>
> After two weeks reading newspapers from China I really wonder whether
> the "D" in DAML+OIL is such a good move for an international used
> language.
>
> Greetings,
>
> Dieter
>
> ----------------------------------------------------------------
> Dieter Fensel
> Division of Mathematics & Computer Science,
> Vrije Universiteit Amsterdam,
> De Boelelaan 1081a, 1081 HV Amsterdam, NL
> The Netherlands
> Room number U3.25.
> Tel. (mobil): +31-(0)6-51850619,
> Fax and Answering machine: +31-(0)84-872 27 22
> Email: dieter@cs.vu.nl
> http://www.google.com/search?q=dieter
> Privat: Liendenhof 64, NL-1108 HB Amsterdam, The Netherlands.
> Tel.: +31-(0)20-365 52 60.
> ----------------------------------------------------------------
> The information transmitted is intended only for the person or entity to which
> it is addressed and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of, or taking of any action
> in reliance upon, this information by persons or entities other than the
> intended recipient is prohibited. If you received this in error, please
> contact the sender and delete the material from any computer.
--
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
This archive was generated by hypermail 2.1.4 : 04/02/02 EST