Format for submitting program data

This page describes the format that constituent meetings (the seven main conferences and workshops) should use for submitting program data for inclusion on this website and in the printed FLoC program.

Traditions apparently differ among the main conferences about the extent to which the affiliated workshop are considered part of the conference. For FLoC programming purposes we have decided to view each workshop as a independent "conference" in its own right - that is, if the workshop organizers want to have its program appear on the FLoC website they must submit it separately.

Final decisions have not yet been made about how tutorials are to be treated program-wise. Peole who have a stake in the programming of tutorials are invited to send their thoughs to Henning Makholm <> and Andrzej Filinski <>.

### Basic data model

The following is the basic data model that all programs must adhere to. Sorry if it seems a little formalistic, but with the number of conferences we have to fit together, we need to mechanise much of the program production, and these are the assumptions our scripts will rely on:

1. Sessions
1.1. Every activity that appears in the program for one of the CMs is in a session. Dinners and other non-technical events are sessions, too (but see 1.8).
1.2. Following section 7 of the JRA (joint responsibiliy agreement) governing FLoC, sessions must adhere to thse constraints:
• sessions must begin and end on the whole or half hour
• no sessions during the morning break 1030--1100
• no sessions during the lunch break 1230--1400
• no sessions during the evening break 1530--1600
For workshops, these requirements are only strongly encouraged, but please note that refreshments and lunch may not be available outside the FLoC-global break times.
1.3. As a rule a session should be the largest continous amount of conference that does not include lunch or refreshment breaks.
1.4. A session may have a heading, or a session chair, or both.
1.5. Two sessions may be scheduled back-to-back if it is important for them to have different headings or different session chairs.
1.6. The common lay-out where a one-hour invited talk is followed by a number of half-hour contributed papers should be presented as a single session. (This is for consistency across the entire FLoC program).
1.7. The room assignment for each session is not part of the data format. Please notify the webmaster and program editor specifically if you have sessions in another room than the meeting's normal auditorium.
1.8. Information about sessions that should appear in more than one meeting's program is kept in a special file maintained by the webmaster and program editor. Such sessions must not be duplicated in the data sent for individual meetings.
2. Session numbers
2.1. A section may have a session number. It will be used in headings on the website and in the printed program.
2.2. Session numbers should be used for exactly those sessions which have primarily technical contents.
2.3. Session numbers should be assigned chronologically starting with 1.
3. Activities
3.1. Most sessions are subdivided into one or more activities. A session may not have any activities, if its own heading is all there should be in the program.
3.2. Most activities are contributed papers or invited talks. Each such presentation
• must have one or more authors.
• must have an affiliation for each author.
• must have a title.
• may have an abstract.
• may be marked as "invited talk" - otherwise it is a contributed paper.
3.3. A session may also contain activities that are not presentations. Such activities have a heading but no other data associated with it. On the website, the heading may be hyperlinked to an URL of your choice.
3.4. The length of an acticvity must be a multiple of 30 minutes. That is, of course, as far as the program is concerned. It is possible to have an activity named, for example, "ten-minute presentations, to be signed-up for at the conference".
For workshops, this requirement is only strongly encouraged, but please note that failure to observe it will lead to less "browseability" between parallel meetings.
3.5. If a session has activities their length must add up to the total length of the session.

### Actual data format

For a conference named FOOBAR, the program data goes in two files named foobar.bib and foobar.pgm.

The .pgm file defines the meeting's program except for actual paper titles etc. in a simple line-oriented format. The .bib file is a BibTeX database that contain information about presentations.

Why BibTeX? Because the mechanics of delimiting fields and such in that format are widely known, so we don't have to explain a scheme of our own, and because BibTeX databases, unlike XML, are convenient for hand editing as well as machine generation. Also, we speculate that somebody on the program committee is probably going to type in at least authors and titles as a BibTeX database anyway.

Below is an example .bib file for the hypothetical workshop "FOOBAR 2002".


@inproceedings{DuckDuckDuck:FOOBAR:2002,
author = "Huey Duck and Dewey Duck and Louie Duck",
institution = "Clinton Coot College, USA",
title = "A Game Semantics for Guarded Interrogatives",
pages = "2--20",
abstract = "We propose a novel formalization of the
semantics of guarded quantitative interrogatives.
Our semantics draws heavily on ideas from game
semantics, and is shown to be sound with respect
to the classical fragment. Furthermore it is
naturally total, and assigns to phrases such as
How much wood would a woodchuck chuck if a
woodchuck could chuck wood?'' a purely imaginary
valuation consistent with that of the~Guidebook."
}

@inProceedings{Fiddler:FOOBAR:2002,
author = {Walt Fiddler},
institution = {Hogwarts School of Witchcraft {and}
Wizardry, UK},
title = {The Pun And The Sailor},
pages = {21-28},
abstract = {We present \textsc{Seaman}, a system for
reasoning monastically about $\xi_2$-complete
type systems.}
}

@inproceedings{Godel:FOOBAR:2002,
author = "G{\"o}del, Kurt",
institution = "Princeton University, USA",
type = "Invited talk",
title = "On formally undecidable Propositions of
{Principia Mathematica} and related Systems {II}",
pages = 1,
}

@InProceedings{RaunSeedle:FOOBAR:2002,
author = "Kefas Raun and Eric Seedle",
institution = "{Emerald, Inc.}, Brutopia and
University of Calisota at Goosetown, USA",
title = "One Hundred Percent of Everything is Nonsense",
pages = "29-152",
analyzing the contents of scientific and
philosophical claims. Examples are provided which
clearly show that all of philosophy as well as
everything ever said or thought by any of my
opponents is \emph{pure nonsense}. \\
attacks are provided.",
}

• The citelabels in the .bib file should follow the rough scheme in the example. This is for consistency in the all-of-FLoC bibliography we will be compiling.
• The author and title fields are as in standard BibTeX. Please note non-initial upper-case letters in titles will be downcased by our BibTeX style unless protected by an extra level of braces. Remember to protect proper nouns that appear in titles.
• The pages field is not used for the program or the website, but will be included if we use the submitted .bib file to create a BibTeX database for all of FLoC'02. The field" should be left out (not left blank) until you know the page numbers. It must be left out for presentations that do not correspond to papers in the proceedings.
• The institution field gives the affiliation for each author. It must contain either as many institution names as there are authors, separated by "and", or exactly one institution name. In the latter case, the same affiliation is used for all auhtors.

We use the name primitives of BibTeX to take the "institution" field apart, so use braces to protect institution names that contain commas (except for the comma before the country) or the word "and". The program that produces the FLoC website requires that someone who has a paper at two submeetings has the same affiliation in both places, so some common conventions for formatting the affiliations should be followed to minimize the workload of the webmaster:

• The institution name should be in English
• Do not abbreviate "University", "Technical" and similar words (abbreviations are applied automatically when the web site is generated, but should not be present in the input).
• A city name should be included only if it is part of the institution name, or is necessary to distinguish between geographically separate sites of the same institution. In any case, do not put a comma before the city name.
• For numbered universities (such as in Paris), use Roman numerals.
• If the institution name is long ("National Advanced Research And Innovation Network For Information And Automation Technology") give its common native acronym followed by the city. Some common examples:
• LORIA Nancy, France
• INSA Rennes, France
• INRIA Rocquencourt, France
• DFKI Saarbr{\"u}cken, Germany
• NASA Ames, USA
• NASA Langley, USA
• Instead of names of the form "IBM Research Labs, Israel" write the name of the parent organization and perhaps the city name if they have multiple reseach sites: "IBM Haifa, Israel"
• The type field should be "Invited talk" for invited talks. It can also be "Invited tutorial" or something similar if you want to have different kinds of invitees (but "Invited talk" is magic, because its "author" will be listed as "invited speaker" on the meeting's front page). The type field may also be used for things like "Position paper" or "System presentation" if you want to differentiate between multiple classes of other presentations. It should be omitted for normal full-length technical papers.
• The abstract field, if present, should contain self-contained LaTeX source fot the paper's abstract. Use \\ for paragraph breaks within abstracts. TeX-style "%" comments must not be used in the abstract - they get munged by BibTeX. We suggest that program chairs ask the authors to submit "abstract" fields along with the final papers - the deadline for submitting abstracts to the website is set to be just after the latest of the final-paper deadlines.

The BibTeX entries may contain LaTeX accents, simple markup such as \emph{...}, and small formulas such as $\lambda$ or $O(n^2)$. We will convert them to HTML when posting them on the website. Do not put any HTML markup in the BibTeX file.

Below is an example .pgm file. It specifies the syntax better than trying to explain it verbally.


Session 1: 2002-07-26 1400-1530
Chair: Hamlet, Prince of Denmark
60 min Godel:FOOBAR:2002
30 min DuckDuckDuck:FOOBAR:2002

Session 2: 2002-07-26 1600-1730
Chair: François Jönsson
30 min Fiddler:FOOBAR:2002
30 min RaunSeedle:FOOBAR:2002
30 min "Discussion" /FOOBAR/discussion.html

Session: 2002-07-26 1900-2030


The "Heading" and "Chair" lines are both optional. They should be omitted rather than left blank if the session has (yet) no chair or no heading.

Each activity line refers either to citelabel from the .bib file or to a non-presentation activity whose heading (in quotes) is optionally followed by an URL relative to http://floc02.diku.dk/.

### A syntax and consitency checker for the data files

We have developed a small set of perl scripts that tries to catch common formatting or consistency errors in .bib and .pgm files. The checker, named "flint", can be downloaded from http://floc02.diku.dk/flint.tar.

If you at all have the possibility, please flint your .bib and .pgm files before you send them to us. This will save time for error correction for you as well as us.

What is described above is the format for full program data. In practise, the data will be given in installments. For example, the list of accepted papers typically become available before their abstracts or slot assignments.

Program chairs must keep local copies of the files they send us. The ONLY way to update the program data on the website is to send entire fresh files. Deltas or verbal descriptions of changes will not be accepted.

If we need to make format changes to the files, we'll send back corrected files to the sender in question, and we expect that the same corrections are present in later files we get.

The following deadlines must be observed by main conferences. Of course submissions before the deadlines would be welcomed. Workshops can lag behind according to their faster organization process.

• Sun March 10 - .pgm file with session times, and mock-up program entries like
      60 min "Invited talk"
30 min "Contributed paper"

(please use these two exact heading strings as long as you only have mock-up data).
The exact times for starting in the morning and ending in the afternoon are not of vital importance yet; they can be changed later. Auxiliary sessions such as business meetings or dinners are important here - please tell us about them as soon as decisions are made.
• Thu April 4 - .bib file with "author", "institution", and "title" fields.
ICLP and TABLEAUX have later author notification deadlines, so they get to wait util Wed April 17 with this information.
• Sat April 20 - .pgm file with preliminary slot assignment for each presentation
• Wed May 15 - .bib file with "author", "institution", "title", and "abstract" fields.
• Mon June 17 - Deadline for everything that needs to go into the printed FLoC program. That is, final versions of entire program, including session headings and session chairs.
• Mon June 17 - "page" fields in the .bib file (page assignment for the proceedings ought to have been finalized by then), and, if possible, a @proceedings record for the entire proceedings in the .bib file. We'll insert "crossref" fields in the records if you don't.

### Where to send the files

Send your .bib and .pgm files as email attachments to Henning Makholm <> and Andrzej Filinski <>.