Project Publication on the Web — IV

Andrea Vianello, Intute, and Harrison Eiteljorg, II

(See email contacts page for the author's email address.)

In this fourth and final article in our series concerning the use of a web site to publish the results of an archaeological project, the authors will concentrate on the basic issue of publishing final reports and analyses. [Recommendations aimed at chief geeks are occasionally presented, in brackets and in this color, as tips. Readers will note that the authors do not always agree as to those recommendations. This is not an area with obvious, settled answers to all the important questions.]

The final reports and analyses will be the culmination of the scholarly endeavor and will also be the culmination of the work to create the web site. They should be different from paper publications in ways made possible by the electronic media, including such simple things as color images and such complex ones as links to maps and models. At the same time, they should utilize the hidden advantages of web publication, providing ways to update, question, comment, or otherwise augment the documents.¹

To begin, the final reports and analyses should be treated as any project's final work. They may be multi-authored or not, divided into multiple volumes or not, presented one-at-a-time or not. Putting these documents on the web should not change their character in that sense. They should, of course, be better and more fully illustrated because doing so imposes no significant extra costs. They may also be longer and/or more inter-linked because such choices also impose no significant monetary costs. Similarly, these documents may refer to or link to accompanying data files in ways that are made possible by the media, ways that are difficult or even impossible in a paper-publication approach. For instance, a table may be defined by search terms applied to a complex database, leaving it to the user (or to underlying software) to create the table on command. [TIP: To make use of hypertextual features maintaining a simple workflow, accessibility, and a degree of future-proofing by following standards, Mr. Vianello recommends limiting such features in any programs being used to the current standards for hypertexts, HTML at the time of writing. Most programs (including PDF producers, Office suites, and Web authoring tools) will output files that can easily be converted to standard HTML; no proprietary or exclusive features should be used. The chief geek should select early an open standard such as HTML5 and ensure all hypertexts, regardless of their publishing format, can be converted to such format. Mr. Eiteljorg would disagree only in that he would suggest being careful to avoid moving to the latest standards too quickly. It is easy to aim for the leading edge and find oneself on the bleeding edge instead.]

Any project's final work will — in some but not all environments — demand peer review as part of the preparation process. Electronic publications will be no different in that regard. Depending upon the environment, peer review may be an issue.

An unexpected benefit of the electronic-publication approach is the potential to put multi-authored documents on the web in pieces as the authors provide them, removing the debilitating impact of the single scholar who fails to produce his/her part of a multi-authored volume on time. This, of course, is not helpful if the missing document must be referenced by others or if it is otherwise required by the nature of the discussion. However, if one person's work stands more or less alone, its absence need not delay other authors' works.

Approaching the task of preparing these documents, it seems to us that one pitfall to be avoided is that of conceiving the web publication to be physically similar to a paper version. Unless there is some reason to expect readers to print out the documents in order to use them like books/journals, we believe that these documents should be presented as true electronic ones, not imitations of paper ones. Even if printed versions of the documents seem necessary, we believe that the best solution is to supply printer-friendly documents when required but not to make such documents the standard online presentations; in other words, any document that seems likely to be printed should have a print command that leads to a version of the document optimized for printing rather than for online presentation. That may well mean that the web documents will change as the web continues to evolve, but that seems to us a better solution than trying to prevent change by presenting electronic documents as pseudo-paper ones. [TIP: For changes to contents Mr. Vianello recommends that the chief geek implement a versioning system. Minor edits (e.g. spelling) can be made by the authors without notice, but any other edits should be noted in some way and possibly dated. Published documents must be treated as their printed counterparts regarding contents because they can be referenced by other authors in other works. It is therefore necessary to balance the possibility of easily updating documents at any time against academic rigor in recording such changes. Mr. Eiteljorg, on the other hand, believes that versioning is critical for preliminary documents and data sets but inadequate for published texts. That is, while he, too, would require versioning for data sources and preliminary publications, he would require that changes to published textual material be made in new documents and would permit no substantive changes to published documents. He sees this as necessary in order to be sure that the record is absolutely clear as to what was said, by whom, and when. He sees the need for an indexing process that would provide information about any updated documents, showing originals and updates in such an index, and a mechanism for linking documents that includes changes to originals that have been found wanting only in the form of links with some standard statement such as, "New information has obliged us to revise statements made here. See . . . ."]

Using the web as a publication medium permits the “publisher” (the project director or editor in this instance) to divide documents into smaller pieces, each separately accessible; let some portions be presented as sub-parts of a larger argument; include, on separate pages, material that might be taken for granted for most readers but not all; or pursue some other way to use electronic presentation to improve the utility of the result. While one must take care not to do things simply for the novelty, using the possibilities of the medium is only common sense.²

Another implication of the discussion to this point is that data sets — either those created by the project or others used in the course of the project but created elsewhere — should be integrated into the publication plan so that data and commentary are linked and available together. This action, the linking of the data and texts, should only be done after careful testing of the data and the links, of course, a reminder that all the activities discussed here need to be thoroughly checked to be sure that all parts of the site function as desired. [TIP: Mr. Vianello recommends that documents approaching publication status should be uploaded on a restricted space of the publishing server. All team members should contribute in checking the appropriate interlinking of the various parts authored and provide some proof-reading or even peer-review if possible. Once ready, the documents can be easily moved to the public portion of the server. Mr. Eiteljorg would expand on the foregoing to urge placing the responsibility for managing such tests and checks with the chief geek, making certain that there is one person ultimately responsible for the process — and the results.]

There may be an implication in the foregoing that the decisions about publications ought entirely to be made by the project director and the chief geek. That is not true. Individual authors surely deserve to be involved in the design of their own presentations. Their voices should be heard. That is not to say that the authors should have final control, but it is to say that the authors should be active participants in the design process.

One of the most problematic aspects of publishing a project's work on the web is the difficulty of getting good peer review in advance of publication when the project is not large enough to have its own editor (to serve as conduit to peer reviewers) as part of the staff. While not all projects will exist in an environment requiring or expecting peer review, anonymity is critical to good peer review and virtually impossible in a setting where there is no person to act as the conduit between authors and reviewers. Absent a publisher or editor as an intermediary, the reviewer would naturally assume no anonymity. There is no obvious work-around for this, but we would suggest that this is an opportunity for professional organizations such as the European Association of Archaeologists or any of the national archaeological organizations to assist. While the authors cannot point to any extant assistance from such organizations as an example, it should be possible to form a committee of any such archaeological organization and to have that committee serve as the intermediary, passing prepared materials from author to reviewer and passing comments back to the author while maintaining anonymity and a respectful, cooperative process. The organization might then offer some form of assurance to readers that the materials have been properly peer-reviewed. There are surely other ways to accomplish peer reviews, but some such method is required. Whether peer review is used or not and whether the project directors see a need for it or not, the website serving as publication medium should clearly indicate the presence or absence of peer review for the content of the site.

The analytic side of these matters may be somewhat less straight-forward. That is, one would expect a publication to present the results of analytic procedures. Using the web, on the other hand, should permit any such analysis to be performed "on the spot" in the sense that it should be possible for any reader to find the raw data and analyze those data him/herself, mimicking any analytic process performed by the authors, in order to confirm the results. As a result, no analytic process should be referenced without a clear indication of the nature of that process and the parameters used so that it can be duplicated by a user — even if there is an automated way to perform the process on command.

We take it to be a given that the raw data will be available to all as part of the publication process — at least in the forms of whole files in proprietary or, preferably, open formats. As a result, far more analytic processes can be carried out and, as necessary, verified. This, of course, is the critical core of the scientific method: experiments that can be replicated so that the "facts" are not in dispute. For archaeological uses, there is an additional benefit; having access to the raw data permits other researchers with relevant data to combine their information with the information from the project so as to develop a larger corpus and, eventually, to perform analyses on such larger corpora. The archaeological record is fragmented, and access to the raw data makes possible some unification.

The final and probably most contentious part of this process is finding ways to permit discussion, change, evolution of the results. Ideally — and we recognize that the ideal may not always be attainable — the site will provide some way for other scholars to react to the publications, a mechanism for another scholar, for instance, to question analytic results if his/her replication of an experiment seems to yield different results. That process should not be public from the beginning in our view but should involve the kind of frank, honest debate that is best carried out in private. At the end of the process, however, there are multiple possible outcomes and multiple ways to handle matters on the website.

If outside scholars and project authors ultimately agree that a given analysis was correct, despite an objection raised, there may be no need to do anything. On the other hand, the dispute may be one that will happen again and again unless the issues (e.g., starting parameters for some statistical process) are discussed openly. In that case, there might be good reason to add an article to the web site explaining the issue(s).

If an outside scholar persuades the author that the original publication is incorrect — whatever the reason — some form of correction is warranted. That correction, however, should not appear as a change in the original publication lest the record be muddied. As noted above in a bracketed tip, the authors do not necessarily agree as to the best mechanism here. Mr. Vianello prefers a versioning system, as established by the chief geek, and allowing changes to documents. Mr. Eiteljorg prefers a system that requires new documents to correct old ones with an index to lead to all documents, allowing no substantive changes to posted documents other than pointers to documents that contain corrections. He would recommend a standard approach to such changes so that any alteration of a document is noted in the same fashion and with the same verbiage. Both authors recommend a master index on the website that shows all publications and notes those that have been updated, a short explanation of or pointer to the portion of the original publication at issue and with some way of referencing the publications under consideration. (Note that this does not require that all publications be on the project web site. Note also that the same system may be used for preliminary publications.) The authors cannot pretend to have considered all possible ways of dealing with the need to add changes, but they do believe strongly that one of the most important benefits of electronic publication is the potential for open discussion and for change.

There remains the unspoken possibility of an outside scholar unable to convince the team of an error and equally unable to agree with the original interpretation. It seems preposterous to insist that the project site provide a forum for a view rejected by its own scholars, but, at the same time, the project site should be the locus for all works about the project. So we suggest that it is not the responsibility of the project to see that such contrary interpretations be published but that it is the responsibility of the project to be sure that any contrary view that has been published after a reputable form of peer review be noted — presumably in the master index referenced above. Such a notation should make it clear that the views in the new publication are not considered by the project team to be correct, but those views should not be hidden.

This discussion of the final publication process has seemed relatively straight-forward, almost simple compared to the earlier matters. However, that is partly because the matter of peer review was not permitted to dominate the discussion and partly because some contentious issues were relegated to the bracketed tips. In fact, though, peer review can be a major stumbling block for those projects requiring its use, and some of the other issues may be vexing for some projects. Peer review is a matter that cries out for a solution of the kind outlined above, but such a solution will come only if the broader archaeological community demands it. The other divisive issues are not critical; all projects need not reach the same conclusions. They simply highlight the fact that we are still working in uncharted territory.

We conclude by stressing again the importance of planning as much as possible as early as possible. Changes will be inevitable, but careful planning will reduce the number of changes required and the problems introduced by those changes that are required. We also wish to stress again the need for an adviser on technical matters, the chief geek, although the chief geek cannot have all the answers because there is no single way to publish data online. Furthermore, given the pace of innovation in the digital world, the choices will surely be more numerous — and more exciting — in the future. Publishing online, however, already offers many important advantages, and we hope that this series of articles may represent one foundation stone for many such publication projects. In order to advance this cause, the authors have set up a forum at http://webpub.bronzeage.org.uk/ to provide readers with an opportunity for continuing dialog.

-- Andrea Vianello and Harrison Eiteljorg, II

For additional articles in this series, please see "Project Publication on the Web — Addendum," by Eiteljorg at csanet.org/newsletter/winter12/nlw1205.html and "Project Publication on the Web — Addendum II," by Vianello at csanet.org/newsletter/spring12/nls1204.html.

Notes:

1. Whether paper publications are a part of the full record of the project will depend on the project directors, of course. Some would argue that the use of a web site should mean that all official pronouncements of the project should appear only on the website. Others would argue that the website need only point to all such official pronouncements, whether on paper or online and whether published by the project or not. A middle position might be that even paper publications should be available in digital form on the website but that a mixed publication record is acceptable. Return to text.

2. The CSA Newsletter format permits us to remove from an article material that some readers do not need or want, providing it in a separate, linked document. That approach has been used effectively in some cases, but it has been used sparingly, lest it be over-used. Similarly, the narrow-page format encourages the newsletter editor to provide larger versions of images in linked pages; however, doing so for images that do not require the larger versions is pointless. Discretion is an important part of the design process. Return to text.