Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501

Deprecated: Function create_function() is deprecated in /opt/lampp/htdocs/aiedam/aiesite/pmwiki.php on line 501
AIEDAM - SpecialIssues - ForGuestEditors

{This text is based on notes provided by William Birmingham, the previous editor}

These notes are intend to reflect how I, as Editor of AIEDAM, would like to work with you, as a guest editor of a special issue. They should be taken as desiderata, subject to negotiation and evolutionary change. They are not cast in stone. Please ask questions if you aren't sure about something.

AIEDAM is an archival journal intended to reach two audiences: engineers and designers who see AI technologies as powerful means for solving difficult engineering problems; and researchers in AI and computer science who are interested in applications of AI and in the theoretical issues that arise from such applications. Specifically, the journal is interested in the use of AI techniques to a variety of engineering tasks, including, for example, design, planning, numerical analysis, simulation, spatial reasoning and graphics, optimization, process planning and manufacturing.

Note that this means that all papers need to have some AI-oriented content in order to be considered. However, note that the journal is quite generous about what constitutes AI, and is interested in any explicit uses of knowledge or reasoning, as well as cognitive models.

In terms of our interactions, there are three basic issues. The first is concerned with editorial processing, prerogatives and control; the second concerns editorial cohesion and the related (and not untypical) case where special issues derive from workshops; and the third is about the mechanics and timing of assembling a special issue.

Editorial processing and control

My intention is to provide each guest editor with maximum flexibility and control without dispensing altogether with my own responsibility for maintaining the journal at what I hope is a high level of quality and interest. The first part of this issue is the origin of the papers for special issues. Are they invited? Selected from a workshop? Or submitted by anyone in response to a call for papers. Any or all of these mechanisms are OK with me; we've used them all. Whatever the source of the papers, they must each be reviewed in a standard, review process (see below).

It is up to you, as guest editor, to make the initial selection of manuscripts for the issues and to choose an appropriate collection of independent reviewers. I would like to be kept informed about:

  1. the authors and titles;
  2. the reviewers of each paper; and
  3. the reviews, the authors' responses to the reviews and your intended decision, before you formally notify the authors of final acceptance.

In addition, I may need to see a copy of selected submitted manuscripts -- especially if there are contradicting reviews.

When you are inviting submissions, you need to be prepared for the circumstance that papers that you solicit may not be reviewed favorably. Of course, if you're only dealing with a Call for Papers (CfP), then there is less likelihood of an embarrassing scenario, although even there you may have to find a graceful way to refuse possible submissions.

The review process I normally follow on unsolicited submissions is that each paper is reviewed at least twice and usually three times, with one reviewer typically chosen from the application domain and a second reviewer chosen from the AI/CS side of the house. I also try to include one senior reviewer, even if it isnt quite their area, just to test for readability and general quality.

If reviews are, on balance, favorable, I accept the paper conditionally and ask authors to submit a revised version of the manuscript and an annotated copy of the reviews that indicates how and where the authors have responded to the reviews. Then I will make a final determination of whether a second round of reviews is needed. In the case of a split decision, I seek an additional review (or reviews) before deciding.

Where possible, please share all the reviews of a paper with all of its reviewers. However, as with returning reviews to authors, confidentiality must be maintained.

Finally, to aid in the process, please make sure that you note the following:

  1. the Reviewer's Evaluation Form which can be shown to the authors in advance to show what criteria are used; and
  2. the Author's Checklist for submission of accepted papers, which is of particular interest to the publisher. A completed copy of the checklist is needed for each submitted paper.

Note that I will make a special version of the Reviewer's Evaluation Form especially tailored to your special issue, and can arrange for it to email all reviews to all the co-guest-editors (as well as me). I strongly urge you to use this method.

As I normally deal with unsolicited manuscripts I don't worry too much about where the papers originate, although I routinely return (i.e., unreviewed) submissions that are clearly inappropriate for the journal, or submissions that are unremarkable applications (e.g., A rule-based system to do X). Interesting and deeper applications, however, do appear in the journal as Practicum Papers, so such papers could be included in a special issue. They must however be helpful, offering advice about the suitability of a particular technique for a particular situation.

I also urge you to try to return papers that are essentially the same as papers that have already appeared elsewhere. This means that workshop or conference papers, for example, must be extended and rewritten as they have already been "published".

Under special circumstances, it might be appropriate that you, as guest editor, solicit an invited article from a prominent member of the community to cover the basic background and evolution of a field, or alternatively to act as a discussion point. It would not be considered a paper as such, and hence it would not subject to the usual review procedure, although some review for style and relevance is appropriate. This would be in addition to the guest editor's basic introduction to the subject, workshop, papers in the special issue, etc.

Editorial cohesion: the role of workshops

The point of a special issue is to assemble a body of work that reflects the state of the art and the direction of some application technique, and to provide results that will be of interest to the journal's audience. The body of work should be introduced by a brief overview of the topic, its utility and importance, and the roles played by the papers in the special issue. It is the responsibility of the special editor(s) to craft this introduction.

Should special issues reflect a workshop in a documentary sense? Or should they just derive from workshops? If you are working from a workshop base, I recommend you ask the authors of the best and most interesting workshop submissions, and that you try for a broad spectrum of work (in terms of ideas, institutions, and geography). This aspect does have ramifications in terms of how many papers (and of what length) are solicited for a special issue. A useful and practical starting point is that five or six of the best workshop submissions be chosen for consideration, assuming their quality merits this choice. The guest editor can perhaps include a summary of the workshop as part of the guest editor's introduction.

Calls for papers

Additional (or even all) papers for special issues should be solicited through the publication of a Call for Papers (CfP), even when a workshop or conference is used as a base for the issue. The CfP should be published in AIEDAM (see examples), although the timing may sometimes be problematic. Also do it on my and your web pages, via email lists, newsgroups, and use other hard copy venues. At least send information to the Comp.AI newsgroup, and to the "DRS Design Research News" via Professor David Durling <intuitive@mac.com>

Mechanics regarding the number of papers

A typical issue of AIEDAM is budgeted at about 110 pages in print, and on average we achieve that with about six manuscripts. Under special circumstances, we can probably expand the number of pages somewhat, but the publisher would certainly like to know about that as far in advance as possible.

As a rough guideline on length:

Approx. 1 page double-space typescript = 0.35 of a journal page.

Another way to handle this is to note that approximately 2.3 ms pages corresponds to 1 jnl page. Include figures and tables in the ms page count for this estimate. i.e., a journal special issue should consist of about 240 pages of double-space typescript.

Mechanics regarding manuscript submission format

The specific formatting requirements are detailed on the web at Instructions for Contributing Authors, and on the inside of the back cover of every issue of AIEDAM. The key requirements are that manuscripts must be typed double-space and that originals of figures be included, although originals includes very sharp laser-printed originals. Figures must not be actually placed in the body of the manuscript. All References must be in the required style. The Press is willing to take manuscripts on disk, as long as disk format and the specific word processor are noted. Under some special circumstances we can handle emailed files, but this isn't normal.

Please note that as Guest Eds you are responsible for making sure that all the items in the Check List are actually provided, and that all style rules (especially for references) have been followed. If you don't do this then this slows down the production process, as, for example, copy editing becomes a nightmare and authors may need to be contacted for corrections etc. Your help with that part of the process is very important! (and appreciated!).

Special issues materials/packages:

Collect all the individual papers, with their disks. Make sure that they send them to you, not me. Make sure that you have everything required by the final submission "check list". Package it all up and send it to me via some secure, fast mailing method. I will check it all over again, mark it up if needed, file some items, and forward it to CUP for the production process.

You will be asked to proof read the issue once it is typeset, so please do this as well and as quickly as possible. Typically you will be sent PDF files of all the papers in the format in which they will appear in the journal.

Timing

The drop-dead deadline for submitting all the final copies (including the introduction, final manuscripts, disks and completed checklists) to the publisher is approximately four (4) months before the scheduled publication date. The timing of what you do prior to that is somewhat variable and will be affected by the selection process (i.e., whether papers are invited or come in response to a CfP), the review process, and the feedback-and-revision cycle. One (now experienced) guest editor has suggested the following allowances and schedule as a guide:

Suggested Timing Schedule:
ProcessTime of Each Process (weeks)Total Time After Process (weeks)
Receipt of Paper00
Rejection after Preliminary Reading11
Review Returned by89
Report to Authors110
Resubmission818
Acceptance/Rejection119
Publication1736

I frankly believe this is quite optimistic, unless the starting point is taken as that time when all the papers are in hand. You should allow at least one year (12 months) for this process, and even this assumes that you're operating from a base of papers, such as those submitted for a workshop. In general, perhaps 18 months is a more reasonable timeframe if revisions are included.

You should plan the publication of CfPs to mesh with your schedule and to give authors (and reviewers) plenty of time to respond.

Other Helpful Ideas

The work load involved in organizing such a special issue is far from trivial. Therefore, I strongly encourage special issue editors to consider soliciting a co-guest editor to share in load. However, if you feel that the additional intellectual and administrative coordination required in a collaborative effort outweigh the gains, so be it.

My general advice is to keep good, complete records about every step, correspondence, and decision. In rare situations we might be required to use your records as evidence in a legal case. Make sure that you keep track of submission, revision and accept dates. It will help a lot for you to assign a unique ID to every submission. I will need a list of all the reviewers that you use, as they will get acknowledged in the journal at the end of the year.

At some point early in the process I will need the contents for a web page similar to those you can see via our Call for Papers page for special issues.

The dates are key: your choice! I typically start by putting a dummy page online as a place-holder until all the details are settled. The page forms the basis for an announcement to the AI EDAM mailing list, as well as for the CfP that appears in the journal. You should start collecting names for a special mailing list of your own of people whose work you would like to see in this issue.

If you want to keep a public page for contacting authors and recording special instructions etc. that's good too. It also helps to have a private page (i.e., with no public pointer to it) for showing each other, and me, reviews, reviewers info., ratings spreadsheets, etc etc.

I can provide you with the URL of a Reviewer's Evaluation Form that will be specially tailored to your special issue. It will be based on the standard review form.

The reviews submitted online will be mailed directly to you both, with a CC to me for safety. This system works very well, and I recommend it strongly. Please let me know how these ideas work and how I can help you assemble an outstanding special issue. I will be able to help at every step of the way -- dont be afraid to ask questions. If you want I can put you in touch with previous guest eds. who can make suggestions about what to do to make things easier.