Meeting 1:
3-6 September, 1995 in Mauritzberg, Sweden

The purpose of the meeting was to (1) discuss the possibility and appropriateness of developing a Hypermanual for Logics of Actions and Change within the present Esprit working group Logic and Change, and (2) to set the guidelines for the continued work. The material which had been distributed for the meeting was (a) a partially developed WWW structure suggesting how the Hypermanual could be organized, and (b) a list of concrete questions to discuss, mostly of a practical character.

The following is a list of concrete decisions at the meeting, organized in a somewhat logical order (not equal to the order in which the decisions were taken). The present version of the list is tentative, pending approval from those present. The numbering is for ease of reference. Questions marked in italic indicate points where I am uncertain about the meeting's decision, or the decision was ambiguous or incomplete. Feedback is welcomed on those points. If no feedback is received, I'll leave it as it stands.

1. The participants wanted to go ahead with the project, but restricted to the "Hypermanual" as such. The related proposals for a depository or archive or technical reports, and for a bibliography containing commentary information, were encouraged but not included in the scope of interests of the present group.
2. The name of the structure shall be the hyperguide for logics of actions and change, to be abbreviated as the LAC HyperGuide. Capital G in HyperGuide appropriate? Thus the term "Hypermanual" is abandoned.
3. The importance of making full use of the new medium's possibilities was emphasized. The "table of contents" of the hyperguide (as distributed for the meeting) should be understood exactly as that - a map where one can see what is included - but it is foreseen that the actual order of reading the contents will be different. Some parts of the structure should be seen as a partially ordered graph, which can be explored by the reader with or without the help of "guide" information. The order in that graph indicates definitional order (definitions of a term precede its use), but the reading order may often be in the opposite direction, namely if the reader has a general knowledge but then later needs to go back to definitions for some details.
4. The structure of the hyperguide's essential contents were discussed in depth. It resulted in the decision to use the structure shown in [meet1-contents] Note: the names of logical subdirectories which were decided on the afternoon of the last day have not yet been incorporated in this file. Also, some of the headings are missing, for example for "Planning". Will be corrected.
5. Erik Sandewall and Antonio Porto will together develop the material on "Frameworks". They will also produce an initial scetch for the material on the first three subdivisions of "Logics".
6. Jim Cunningham and Camilla Schwind will together develop the material on "Logics".
7. Jacqueline Vauzeilles and Marcel Masseron will develop material on linear logic (to be reported to Jim and Camilla) and on planning.
8. Camilla Schwind will also develop the material on "Update". Marco Schaerf indicated an interest in the same topic, but had difficulties finding the time. Shall I include you here, Marco?
9. A standardization of the notation for mathematical and logical formulae in the hyperguide was discussed, based on a table of symbols used in the book "Features and Fluents". The meeting decided to use the set of symbols specified in [notation] Please check again that I got it right.
10. It was agreed to introduce a reference language, that is, a formal language with a precise syntax, for expressing scenario descriptions involving actions and change in a uniform and high-level fashion. The name of that language was left open.
11. How about calling it the HyperGuide Reference Language (HGRL) ? I provisorically use that term in what follows.
12. The HGRL will be used as the primary tool for expressing scenario examples, and the various specific ("integrated") approaches which are found in the contemporary literature will be defined and analyzed in its terms. An operational semantics will be defined for the HGRL, using if possible the methods in "Features and Fluents" with the adaptations that may be found necessary.
13. The HGRL will be seen as an alternative to the script-A family kind of languages, and will be characterized by a closer relation to logic. Its syntax overlaps with first-order logic, but involves some constraints and some extensions with special operators. The HGRL will be developed by Erik Sandewall and Antonion Porto, starting from the guidelines that were formulated at the meeting. These are being written down in [frameworks/hgrl].
14. The need for a collection of representative examples was discussed, with Jim Cunningham as the chairperson. The notes from this discussion are in a separate file, [meetings/meet1jc].
15. Hyperguide segments with a substantial content shall be constructed by analogy with ordinary articles, that is, they shall have an author (set of authors) and a title. For reference purposes, they can then be treated as analogous to articles in a "collection" type book.
16. The hyperguide as a whole, and larger parts of the hyperguide, can then be referenced as a composite work with one or a few editors.
17. The permanent availability of earlier generations of hyperguide segments was discussed. It was agreed that such permanence is very desirable, but that there are a number of practical difficulties. (It was not agreed exactly how to solve them). Referencable hyperguide segments shall be marked with a version number and a month of issue; either one of these information shall be sufficient for correctly identifying and retrieving the segment version in question from the archive.
18. The importance of a good introduction to the topic of the hyperguide was emphasized.
19. (I proceed now to the list of fairly practical decisions).
20. It is desirable to have a virtual host name for the hyperguide as a whole. The Linköping participants will investigate how this can be done. Not yet completed, work in progress.
21. We need an addressing scheme whereby addresses to pages within the hyperguide can be kept unchanged as parts of the hyperguide are moved from one host to another. It was agreed to use a syntax as in the following example for references within the hyperguide:

        /hg-lac/logics/modal/
    

    where the first part (hg-lac) shall invoke a script in the current host which maps the rest of the path to a real one, and then returns the intended file (if it is in the same computer system) or requests it to be sent to the user (if it is in another computer system). The work of implementing this was considered small. Lars Karlsson promised to try to do the job until the end of the month of September.
22. The identifiers in access paths shall be chosen as real English words; "mnemonic" identifiers are to be avoided.
23. Two formats are to be used for hyperguide segments ("files"), namely HTML and postscript.
24. Postscript pages are to be generated from Latex.
25. The Latex2e variant of Latex is to be used. However, since then I have used it, and it is hopelessly slow for short postscript files. It seems to do a lot of initialization; maybe the overhead is less damaging for longer files, but since we want to emphasize short files I think we have a problem here. I would propose to change the decision to say that we shall try to write segment source and macros so that they can very easily be moved between older Latex and Latex2e. This will allow using fast Latex while writing.
26. The heading of hyperguide segments ("files") in printout was decided. The file [frameworks/hgrl]. shows an example of the decided format. Except I did not manage to get rid of the page number on the first page, which was intended. Anyone knows how to do that?
27. We discussed the fact that postscript fonts that display well on the screen come out too thick on paper, and vice versa. It was agreed to handle this by keeping postscript files in two versions, namely, a .ps version for printout and a .dvi version for display. Some concern was however expressed regarding the lacking standardization of .dvi. After the meeting I have observed that the ECCC (colloquium on computational complexity) originally used the postscript + dvi scheme, but that they discontinued the dvi:s after a year.

The following items are not yet completely documented in this version of the minutes. They will be included as soon as possible:

1. The agreements about the syntax and font choice in the HGRL have not yet been written out in full.