Difference between revisions of "Initial setup"

Revision as of 07:34, 20 November 2007

Once you have all of the dependencies up and running, you need to begin to design how you want your instance of ARK to work.

There are a number of things to think about before you begin editing the configuration files.

A Name

Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.

What do you want to record?

ARK is designed to be a flexible system, therefore you can pretty much record/store any type of information. However, whilst not essential, it does help to have some idea at the start of the project as to what you want to record. Most archaeological projects will already have paper recording sheets and some idea of how they record in the field. It may be that you already have a computerised database structure that you want to recreate within an ARK instance.

The best way to begin designing your ARK instance is to think in terms of Modules and Fields. An excavation recording system for instance could perhaps have a number of different modules including the Context module and perhaps a Site Photo module, each of which will have a number of fields (SEE AMAZING IMAGE TO EXPLAIN THIS). An Sites and Monuments Record type application on the other hand may have a Monument module with a number of different fields (such as monument_type, etc.).

It may help to sketch out on a piece of paper the initial structure you want and then you can start building it up as you go along. One of the strengths of ARK is that it can be adapted to suit your recording practices, so if you don't know exactly what you want to record at the beginning of the project - you can just add more later. Below is an example of a sketch-up of the Sintana project containing two modules: The completely made up module of Sintana which contained a set of finds points and the Bibliography module. Both modules have a series of fields attached which can be data classes

What subforms do you want?

ARK comes packaged with a number of different subforms, each of which can be used to present different types of information. The subforms can be seen as packages which combine the different fields depending on which data class they use.

Simple one data class subforms

These subforms are very simple since they only require one type of field. The most used example is the text subform (sf_txt) which can display any number of text-type fields for each module. In addition the number subform (sf_number) will take one or more number fields and display, the links subform (sf_xmi) which records links between module items and the matrix subform (sf_spanmatrix) which can be used to record all types of spans as matrices. This last subform is often used for matrices describing context relationships with a span from one context to the next describing how the first context cuts the next. However, this matrix subform has been used with big succes in other modules like the file module to describe the relationship between files where one file can be derived from an older file.

Combined data class subforms

Nevertheless, some subforms display a combination of fields with different data-types. One such is the interpretation subform (sf_interp) which takes a text field, an action field and a date field. This displays one interpretation for a module item (e.g. a context or a special find) which is again chained to a date and an action. Another example of these combined data-type subforms is the events subform (sf_event) which can use a date field or an action field or both a date and action field to display an event which has happened on a specific date by a specific person.