HyperNietzsche
Dynamic Web Site:
Concepts and Structure

J-F Antoniotti

Date: April, $\mbox{\oldstylenums{13}}^{th}$ , 2002

List of Figures

Warning

This paper was quickly built from the slides and the speech that I gave in Munchen on April, $13^{th}$ .

HyperNietzsche clients

To the question "Who are the HyperNietzsche users", we could immediately answer that they are researchers in the Humanities. This implies a number of consequences. Among them, we can cite:

strong habits, mostly coming from their culture of paper : precision in bibliographical references, bibliographical conventions, and different aspects of their working methodology
newer, but as strong as the previous ones are their computer habits ! Most of the time, researchers in the Humanities use sophisticated human/machine interfaces : they are nice and robust. As an example, Mac OS X provides such an interface.

Both kinds of habits are constraints that must be respected. Both of them have immediately driven us to the necessity of codesign: one must give total control of the user interface design to humanities researchers who know about HTML page creation tools, but whan may have only little knowledge of programming language. It seems to be the only way to nicely integrate the HyperNietzsche users habits; we will return to this topic later in this paper.

We should notice that computer habits have an immediate positive consequence : HyperNietzsche users are suppposed to use last generation browsers, with powerful features such as JavaScript enabling and XML processing. This is confirmed by the site access statistics.

At a later time, we could complete the first answer by saying "they are Nietzsche specialists". But, at this level of the discussion, we would like to not emphasize this specialist's domain. One of HyperNietzsche's ultimate goals is indeed to be generalized; from such a generalization, one could create systems such as HyperFlaubert or HyperGoethe very easily. This sounds very good for computer scientist:

generalizable systems must be designed intelligently,
lazy programmers don't have to know much about Nietzsche's work ;)

I will not continue with the description of HyperNietzsche users' needs: previous speakers have done this job better than I could. I would like to skip to a kind of guideline for programmers in charge of the project. Such a guideline is called a set of high level specifications in computer science, and its intent is helping the design of a user satisfying product application.

High level Specifications

From the HyperNietzsche user point of view, we can divide the picture into two big parts: the user may be in a passive mood, so his point will mainly be the consultation of the site. Alternatively, the user may be active, submitting new contributions to the site or, in the case of a scientific comission member, evaluating these new contributions. Let's have a look to these three different kind of users and at the high level specifications they induce:

$\bullet$

From the passive user point of view, HyperNietzsche should be a valuable working frame. This goal would be reached by mean of three offers:

$\bullet$: the first one is the access to certified, high-quality reproductions of pieces of Nietzsche's work that use to be difficult to access. Old editions or original manuscripts are examples of such jewels.
$\bullet$: In the same manner, this user should have access to certified, high-quality contributions about Nietzsche's work, with the same reliability he expects from a well-established publication house.
$\bullet$: The third offer is the possibility to combine different working pieces in a coherent and personalized manner. This is called contextual navigation and relates to the view of a researcher in a library whose table is covered with open books.

$\bullet$

From the active user point of view, HyperNietzsche should be an attractive publication place. This is not a small challenge, if you know about the importance of publication in a researcher's career. Something that is called "publish or perish" in our American collegues' direct style. Some of the images that Internet brings with itself (High-Tech, newness, a distinctive way to communicate) are definitely not acceptable arguments: our users are by no means fashion victims.

To reach this goal, we retain the three main following specifications:

$\bullet$: A clear publication status to answer to the following user's asks: what are my intellectual rights on my paper ? Will the Internet's appetite definitely gobble up my article ? (license term).
$\bullet$: A transparent, peer-review evaluation process, handeled by a editorial board of members are recognized Nietzsche specialist. This means too: an anonymous submission feature, the ability to trace the evaluation history once the judgement has been given, and perfect knowledge of the rules of the process.
$\bullet$: The ability to submit complex contributions such as genetic paths, making extensive use of the hypertext.

To finish with this set of high-level specifications, let's have a word about reviewers: from this particular active user point of view, HyperNietzsche should be of simple use, specially for the following activities:

$\bullet$: voting and reporting,
$\bullet$: getting the other reviewers' responses

A Brief History

Before going to the heart of the subject, I would like to give a short overview of the site's history.

HyperNietzsche v.0.0

The first unofficial version is HyperNietzsche v.0.0. It integrates an astounding number of things such as contextual contribution submission that allows, for example, the submission of a transcription of a manuscript that you are currently looking at. It also integrates a contextual navigation prototype and a quite definitve aspect of what the materials section should be. We can describe materials as a set of Nietzsche's works i digital form that is considered as ground contributions: other HyperNietzsche contributions should grow up from these.

Unfortunately, this version has never been put online. And, quite surprisingly, most of you know its general aspect and functionnalities, as it has been extensively used for demonstration purpose by Dr Diorio all over the world. The main characteristic of HyperNietzsche v.0.0 is to represent the fairly long way from the birth of the HyperNietzsche idea, located somewhere inside the brain of a humanities researcher, to the fingerprint of a computer scientist.

In respect to this, HyperNietzsche v.0.0 is fundamental and has the status of the site's origin and source.

HyperNietzsche v.0.1

HyperNietzsche v.0.1 was a christmas gift, even if one may wonder about Nietzsche's taste for such a thing. It was the site's first version accessible via the Web, and it offered for consultation six old and rare Montinari's essays, all of them in a fac-simile and in a HTML form. HyperNietzsche was modestly answering to one of its first missions : the diffusion of valuable Nietzsche related work.

With this version users did enjoy (at least we hope) the new overall graphic design of HyperNietzsche, that is stable by now.

HyperNietzsche v.0.2

HyperNietzsche v.0.2 opened 3 months later, and it is the current online version. It completely integrates the previous one, and its main novelty is to allow the submission of new essays to publication.

As the previous version locked the users in a passive mode, this version made the active user exist.

Towards HyperNietzsche 0.3

HyperNietzsche 0.3 is the currently developing version. Its main purpose is to reconcile HyperNietzschev.0.0 and HyperNietzschev.0.2. In particular it should give access to materials and to a fair contextual navigation. It should fulfill the wishes of passive users, and trace the route to first and second level contributions such as transcriptions and paths.

This goal should be reached by mean of the experience we gained with previous versions, a big work of structuring the project and, last but not least, the association of four computer scientists. This last point is very new to HyperNietzsche and a sign of good health in my opinion.

HyperNietzsche as a Web app

If you open an introductory computer science book, you 'll certainly see the following def:

App=Data Structure + Control

Data structures are electronic representations of information, while control refers to what we commonly call a "program", that is, a set of instructions that are executed at different steps of the application.

App=ADT + Control

In a better book, you will see that an Application is Abstract Data Type plus Control. ADT are e-representations of information augmented with operations available for these data.

Basically, they are operations of insertion, deletion, updating and access to particular pieces of information.

Importance of ADT

Abstraction permits us to work closer to the high level specification: ADT allows computer scientists to talk about contributions, users, essay pages rather than integers, lists, or pointers. They permit us to respect the functional description of the system and to cope with two fundamental aspects of an application:

$\bullet$: first, the complexity: functional modularization gives a clear view of what the system should be and how its different parts interact. This abstract structuration will be refined at future steps of the project, respecting the so-called cartesian principle.
$\bullet$: second, the planned and unplanned forecoming changes at the functional level or at the implementation (technical) level. A sound module isolation allows more flexibility when we need to change, add or suppress a given module. Moreover, the ADT methodology allows us to prepare ourselves to the generalization of the system in a rather natural way.

Let me show to you a last equation:

Web App=ADT+HTML Processing

This one reflect my opinion that a very big part of a HyperNietzsche-like application control is page creation and form treatement, that is, HTML processing. This is highly disputable of course: the whole process of a new essay submission cannot be considered as HTML processing but I have in mind the two following arguments:

$\bullet$: everything that lies at a higher-level than HTML processing may be integrated into ADT,
$\bullet$: keeping a control part as simple as possible and entirely devoted to HTML processing has a great consequence: while HTML processing is mainly responsible for the site's external aspect, it helps us very much to respect one of our most important specifications: codesign of the user interface.

We may know give figure 1 as a first picture of our system:

**Figure 1:** A first picture
$\includegraphics[width=\textwidth]{server1.eps}$

As we said, HTML processing and ADT are main parts of this one, represented by a dashed box. You may see what's going in an external user request: the HTML processing part translates it into a specific ADT request, receives back data, formats them and sends back an HTML page to the user.

I will speak a little bit about the constraints that such an architecture must respect.

A bad Web app

**Figure 2:** A bad server
$\includegraphics[width=\textwidth]{bad_server.eps}$

Picture 2 reflects what a bad Web app would be. Suppose that the user asks the system for the contribution list. The HTML processing part will translate his request in the following way:

$\bullet$: it begins to recover the contributions' number
$\bullet$: then it loops as many times as there are contributions to recover and format each contribution's data

There is doubt, at least with the monoprocessor hardware configuration that we use, that such a request multiplication would be foolish, and make the system's response very slow.

A good Web app

**Figure 3:** A good server
$\includegraphics[width=\textwidth]{good_server.eps}$

As shown on figure 3, a good HTML processing part should be able to translate a user's request rather directly, and then send this primed version of the request to a proper ADT to recover the wanted set of data.

All of this relies on DBMS request minimization and on a carefully designed interface between the HTML processing part and the ADT. It leads to highly structured data on the ADT side, and to highly structured code on the HTML processing side.

A note about implementation:

$\bullet$: the HTML processing part is mainly written in PHP, but makes extensive use of Apache features. This use is usually implicit : every input and output at the right side of the box passes through the Web Server. Due to the PHP ability of Apache, our user asks for a PHP page and receives back HTML. Sometimes this use is explicit : we use features such as URL rewriting and SSL encryption.
$\bullet$: The ADT's are mainly implemented with PostGreSQL and PHP. The PostGreSQL is in charge of the management of the persistent objects, while PHP is mainly used to implement complex logic. The contribution accepting procedure, based on a difference of votes and on time duration is an example of such a task.

One may wonder about these Web Server, language and DataBase Management System choices. Here are a few good reasons:

$\bullet$: Apache is the only reasonable choice on a LINUX system. It is a high-quality product, and it runs almost half of the Internet sites worldwide.
$\bullet$: PHP and its HTML-embedded nature is the natural candidate to codesign the HTML processing part. Concretely, it means that it is not the HTML part that is embedded in a complex program, making the graphist uneasy, but the exact opposite : little pieces of program are embedded in the HTML page when they are needed. Ideally, it permits to entirely delegate the HTML design to graphists, while programmers concentrate on a separate, complementary part (FastTemplate).
$\bullet$: We needed a powerful tool to implement our ADT. PostGreSQL has been chosen for its stability and its advanced set of features. Although it is not really object-oriented, it allows us to do efficiently all that we want with a litle bit of reflexion and discipline.
$\bullet$: Should we justify the LINUX choice ? It is far more than cultural, it is Open Source, just like the other softwares that I have previously cited. I guess that I will not have to convince anybody here that it is the only way that we should consider if we want to generalize and freely redistribute our system.

From now on, I should mainly talk about HyperNietzsche modules. Modules are very close to ADT in the following sense:

$\bullet$: they hide information and give a high level view of the system,
$\bullet$: they specify the routines that are the ADT's operations,
$\bullet$: they give a rough idea of the data structures that we need.

Modules

General picture

Figure 4 is the general picture of HyperNietzsche v.0.2.

**Figure 4:** Genreal picture of HN v.0.2
$\includegraphics[width=\textwidth]{general_picture.eps}$

You can see the rather central USER module that presents two attributes to the other modules. These attributes are scientific comission member and president. They indicates to other modules if the user is a member of the scientific comission or the president of the association. The two previous case are not exclusive, and they can be both set to false. This is the case of a minimal, regular user.

A user can authenticate himself by adressing requests to the authentification module'sCS member Auth procedure and President Auth procedure. He may identifify himself as an scientific comission member or as the president : each time login and password check is done and, on success, the user attributes are modified accordingly. This module allows the user to also change his password through the Change Password procedure. All authentification procedures are done with the https protocol, that is, login and password are moving in an encrypted form over the Internet.

A user can navigate through the HyperNietzsche contributions by adressing a request to the NAVIGATION module. This module has one attribute as its only entry point: the contribution'ssigle attribute. A sigle is a short word that must be seen as a HyperNietzsche bibliographical internal reference.

CS members can navigate through HyperNietzsche prepublications by adressing a request to the PREPUB NAVIGATION module. This module is a mirror of the previous one. Prepublication and publication sigles live in separate name spaces. Unity is only ensured within both name spaces, and repetitions may occur if we consider the union of these name spaces.

A user can invoke the identification procedure of the CONTRIBUTION module: he obtains in return the list of all the published essays in HyperNietzsche with several datas of interest (authors, essay language,...). The arrow between contribution and navigation modules represents the ability to navigate into each essay from the list.

The ACCEPTATION modulehides the implementation of submission accepting rules in HyperNietzsche. For each submission, it computes the daily submission score and the remaining time to acceptation or refutation. If this time is up, this module accordingly changes the submission status. This module is not user-dependant: it is invoked the first minute of each day.

The PREPUB CONTRIBUTION module is more complex:

The submission procedure allows any user to submit an essay to HyperNietzsche. This can be either an anonymous submission, in the case of first submission, or an identified submission, in the case of a republication. In the latter case, a user must register himself into HyperNietzsche and provide his name, surname and e-mail.

The identification procedure is twofold. It allows scientific comission members to get the list of currently evaluated essays, with several fields of interest such as positive and negative vote number and a navigation link for each essay. It also provides to reviewers a good indication of the remaining time to accept or refuse each submission.

When invoked by a regular user, this procedure hides all the previous informations and it only provides the current status of the submissions, that is accepted, refused, or currently evaluated.

SC members can evaluate each submission by the vote procedure and report procedure. Each vote is immediately counted in the daily submissions score.

The identification procedure allows users to identify themselves when they learn that their submission has been accepted.

The president can publish accepted essays using the coresponding publication procedure. Accepted essays are submitted essays that have succesfully passed the peer-review process. It is the president's ultimate responsability to definitively publish this submission into HyperNietzsche, and he has to cope with licence term agreements from the submission's author.

`USER` module

The USER module's particularity is to lie at the border of the client/server application. On the client side, it is a browser with a particular signature that allows our server to recognize him. This signature is in fact a session id, that is a long alphanumeric word.

On the server side, this key allows the recovering of user specific values, such as scientific comission member and president attributes but also the user language. This mechanism is known in PHP as session variables and one must think of it as a micro DBMS.

On the client side, the session id may be stored in cookies, or it may be sent to the server with each URL request. In any case, the key must be sent at each request. This is due to the stateless nature of any Web server, that never maintains any named link with its clients: the server tends to forget about previous requests, and users have to identify themselves at each request. The cookie solution is optimal because this negotiation is then transparent to the user. The latter solution is safer because clients may disable their cookies features but it leads to long and complex URL. HyperNietzsche v.0.2 use both solutions, and we haven't received any problem reports about this. It certainly means that our users do always accept cookies.

On the previous general picture, each incoming arrow to the USER module should be understood as going through the HTML procesing part. This is of particular importance, as the HyperNietzsche multilinguism is entirely included at this level. Each PHP script that results in an HTML page begins to recover the right translation of each word that must appear in the page. This request is adressed to a specific translation database, and respecting what a good Web application should be, this task is done in only one query.

`CONTRIBUTION` module

**Figure 5:** The `essay_frame.php` script
$\includegraphics[width=\textwidth]{essay_frame_script.eps}$

Let's speak about the CONTRIBUTION module and about its only identification procedure. You can see its source on figure 5. This procedure results in a frameset, that is a page that is separated into two frames: the search frame and the list frame.

The search frame allows the user to construct a search request on the title name, author name and surname, essay language, essay publication status and essay type (first publication, republication or fac-simile). This request is then sent to the list frame.

The list frame displays the essay list according to the research criteria if there are some, or with the defaults. At each row appear the corresponding authors, the title linked to the navigation module, the language of the essay and so on. Each of these relevant fields appears in its own column, and one can click on these columns' names to accordingly sort the list. The essays are displayed ten at a time, and little navigation arrows allow to pass to the next or previous ten essays. The last two actions result in a reactualisation of the same page. This script self-calling preserves the search criteria and the sort order.

Each time this script is called, a particular request is built on the search criteria and sent to the DBMS. This is coherent with our ADT paradigm.

Even if I should mainly talk about ADT, you can get from this example an idea of how HTML processing works. This script creates an empty page and delegates the content to the frames. Besides it creates the page title in the way that we already described. The begin.php script recognizes session id and sets the session variables accordingly. The multilingue_id array is then filled with all the words to be translated. Finally, the get_multilingue_ids.php script sets the $Essay_id variable with the right translation. This value is then used inside the <TITLE> tag.

`NAVIGATION` module

**Figure 6:** The **`NAVIGATION` module**organization
$\includegraphics[width=\textwidth]{navigation_mod.eps}$

The NAVIGATION modulehas a complex structure, drawn on figure 6. Even though its use is now limited to the essays, it has been virtually designed to work with any kind of contributions.

The first thing to understand about this module is its ability to display an essay page or the very top of the essay, that is its cover page. In the latter case, the user will get bibliographical information (essay's title and authors), the contextualisation of this essay, and he may make one step down in the granularity level, clicking on a link and getting the first page of the essay. For this purpose, the navigation module calls back with the first page's sigle.

At calling time, the module begins to get from the input sigle the corresponding object's attributes. They could be the format of the eventually corresponding file, its granularity level, the title of the corresponding contribution, or the sigle of its first child in the granularity level. It then passes some of these parameters to the CONTEXT part and to the DISPLAY part. As you already know, the CONTEXT part is very poor by now. But it is able to recognize a page and to display a little printer icon with a link to a printer-friendly version of this page.

The DISPLAY part begins to test on the granularity level and accordingly calls different routines. The FRONTISPICE one is called on the top case and it will create a cover page from essay's attribute. The DISPLAY HTML and DISPLAY IMAGE ones are called in the case of a page, depending on its format. Finally, in the case of an IMAGE PAGE, the image is displayed with a navigation bar that allows user to go to other pages of the essay, keeping the same level of granularity and calling back the module. In the HTML case, the essay has only one page, that contains all the pages that a paper version should have. One could also imagine a navigation bar for these essays, based on internal references inside the same HTML file by means of relative links. Due to our high-level design methodology, it will not be a big deal to specify and implement such a feature.

I will not talk about the prepub navigation module, as it exactly works in the same manner, the opposite side of the mirror being the realm of submitted contributions.

`PREPUB CONTRIBUTION` module

We did talk about the identification procedure of the CONTRIBUTION module. As I said, this module identification procedure is twofold: the regular user version is very comparable to the previous one. The scientific comission member is quite different, but works in the same spirit: there is an evaluation-oriented search frame and a list frame.

Of particular interest is the submission procedure. Let's have a look at the picture 7.

**Figure 7:** The `submission procedure`
$\includegraphics[width=\textwidth]{submission_proc.eps}$

The user may submit an essay that has never been published before, or an essay for republication. According to this dichotomy, we switch to ANONYMOUS SUBMISSION in the former case, or to the IDENTIFIED SUBMISSION in the latter.

The first routine mainly asks for the HTML file and for a password. This last one should help for identification on submission acceptation.

The second routine ask for the HTML file and for the complete bibliographical references of the already published essay, including author name and e-mail. If there are be several authors, this is done by zigzaging between the IDENTIFIED SUBMISSION and the AUTHOR REGISTRATION routines.

Both SUBMISSION routine then call the corresponding PREPUB CREATION operations, that are part of the prepublication ADT, and that are implemented in POSTGRESQL.

Implementation consideration

Think about objects, implement with a DBMS

As I said many times, it is of great importance to keep a high-level of abstraction during the whole design process of our system. We must think about objects, and implement them with the developement tools that we have chosen. PHP has some specific object-oriented features, but they are still in their infancy. I think that a major reason of that surprising immaturity for a language as rich as PHP is the basic contradiction between persistant objects and the primary goal of PHP: an HTML processor working as a sub-module of a Web Server, with all the stateless consequences that it implies. Once a page is created, PHP tends to forgot about used information, and we have seen before that all server-side memory features never come for free: this is why a DBMS is the natural complementary tool for a Web server as soon as a real Web application is wanted.

I don't want to say that objects in PHP are useless nor that they do not have a future. I simply think about PHP objects just as a clever way to structurate the Web app code. This can be done by a good programming methodology and it is not an answer to our fundamental needs.

We then must turn ourselves towards the DBMS. Although fully object-oriented DBMS are a real need, they are still rare, at least in the Open Source community. So our only remaining choice is to get a powerful DBMS such as PostGreSQL and to manage our constructions with the help of its many features.

contribution objects

To illustrate our ideas on a concrete case, let's focus on the contribution objects implementation in PostGreSQL.

First of all we use sigles as a general reference mechanism for these objects. This means two things:

$\bullet$: this mechanism should ensure the unity of sigle in a reserved name space
$\bullet$: given a sigle, we must implement the corresponding object's attribute recovering task

This is done in a rather simple way: there are two tables all_sigle and all_prepub_sigle that store each published or submitted contribution sigle, with the table name where the corresponding attributes lie. The sigle field is the primary key of these tables, insuring the unity. This has an important consequence : all the attributes of a given object should lie in the same table. This is in contradiction with the beautiful second and third normalization principle of the relational database theory that tells us to dispatch as much as possible the information over the system tables. But doing this, we gain a lot in the response time of the system, and my point is that the main drawback of that approach, namely information redundancy, data incoherence and management difficulty can be avoided by a strong implementation of these objects's constructors and attributes recovering methods. Moreover, it is a positive fact that we rarely need to update our contribution objects. But even if it would be the case, we could write updating methods in the PostGreSQL Procedural Language.

PostGreSQL object constructor

An essay submission calls an essay constructor, with all the desired values to initialize its attributes. Concretely, this constructor is implemented by the two following componants:

$\bullet$: A submission mask, that is a PostGreSQL table, that is the constructor interface within PHP. This table is virtual, in the sense that it never retains data. It is used as a one-way gap between PHP and PostGreSQL.
$\bullet$: The second part of any constructor is a stored submission procedure, that is triggered on insertion in the previous table. Its job is to dispatch all the data in the hard tables of the system.

Going always deeper into the implementation details, let's have a look to the constructor for a page object:

Constructor for page

$\underline{\relax\smash{\hbox{s}}}$ ubmission mask scheme

Name Type Description

page_sigle varchar(255)

essay_sigle varchar(255)

directory varchar(50) NOT NULL

format varchar(50) NOT NULL

file_name varchar(50) NOT NULL

ordering_field_value varchar(50) NOT NULL

brotherhood_pos int4

You can see here the table scheme, that is its fields. You will notice constraints on some fields, such as directory and filename. It means that the constructor will reject any attempt to construct a page without a directory and a filename. These constraints should be more complex: as an example, we could do some pattern matching on any field. The ordering_field_value is used to compare brothers. In the case of a fac-simile, all the numerized pages are considered as childs of the essay, and this field is the page number that may be roman of course. From this one, we may compute brotherhood_pos, a real number that gives the position of the page in its brotherhood. This is of importance when we have to have access to next or previous page.

$\underline{\relax\smash{\hbox{stored procedure}}}$ Now, have a look at the stored procedure. You may see extracted comments from the PostGreSQL procedural language code of this procedure on figure 8 .

**Figure 8:** The stored procedure of the page object constructor
$\includegraphics[width=\textwidth]{add_prepub_page_func.eps}$

$\bullet$: If the corresponding essay's sigle is not provided, we begin to recover it from the required directory argument. On failing, the constructor raises an exception that makes the transaction abort. This option is needed by the HTML processing part.
$\bullet$: Even if the essay's sigle is provided, we check it against the directory. It is an example of defensive coding that our methodology allows.

Constructor for essay

$\underline{\relax\smash{\hbox{submission mask scheme}}}$

Name Type Description

submission_date date NOT NULL

title text NOT NULL

language varchar(255) NOT NULL

authors_comment text

directory varchar(50)

sid text NOT NULL

pwd varchar(12)

file_name varchar(50)

file_format varchar(50)

$\underline{\relax\smash{\hbox{stored procedure}}}$ You will see on figure 9 the extracted comments of the essay constructor stored procedure.

**Figure 9:** The stored procedure of the essay object constructor
$\includegraphics[width=\textwidth]{submit_essay_func.eps}$

`list of` method for essays

You will see on figure 10 the extracted comments of the list_of method for essays.

**Figure 10:** `list of` method for essay object
$\includegraphics[width=\textwidth]{view_essay.eps}$

This example should convince you of its beautiful simplicity due to powerful PostGreSQL's VIEWs. The call to view_contributions illustrates the ability to implement attributes recovering method in an incremental, efficient way.

`list of` method for contribution object

You will see on figure 11 the extracted comments of the list_of method for contributions.

**Figure 11:** `list of` method for contributions
$\includegraphics[width=\textwidth]{view_contrib.eps}$

Conclusion

It's time to finish and to give some concluding remarks.

the reality of HyperNietzsche

This talk was intented to make you feel the reality of HyperNietzsche. I hope that this low diving from high level specifications to implementation details has fulfilled this goal.

user centering

HyperNietzsche's primary concern is its community. This means humanities researchers as end-users, but it also means a few computer scientists that are in charge of the project. A sweet dream would be HyperNietzsche becoming a big open-source project, with a great community of excited computer scientists that are contributing to. To make such a thing feasible, even on a little scale, it is of primary importance to keep a tight control at each level of the whole structure.

modular, subject to change

One of the cornerstones of an easy-to-maintain and generalizable system is its modularity. This is why almost half of my talk was about modules and ADT. This kind of project cannot be finalized by a collection of hacker's tricks and superb use of the latest features of Apache v.1.3.

where is the real add-on ?

The really tricky part is an authentic ontology construction between humanities researchers and computer scientists. Such an add-on could never be capitalized without the help of a clean, self-documentating working methodology.

Aknowledgements: many thanks to Thomas Bartscherer, who kindly re-read the original text.

About this document ...

HyperNietzsche
Dynamic Web Site:
Concepts and Structure

This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.43)

The command line arguments were:
latex2html -noaddress -split 0 -white article

`Name`	`Type`	`Description`
`page_sigle`	`varchar(255)`
`essay_sigle`	`varchar(255)`
`directory`	`varchar(50)`	NOT NULL
`format`	`varchar(50)`	NOT NULL
`file_name`	`varchar(50)`	NOT NULL
`ordering_field_value`	`varchar(50)`	NOT NULL
`brotherhood_pos`	`int4`

HyperNietzsche Dynamic Web Site: Concepts and Structure

HyperNietzsche
Dynamic Web Site:
Concepts and Structure