Difference between revisions of "Initial setup"

Revision as of 06:39, 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.

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 six different field types depending on the outcome.

Data-types

• txt
• number
• attribute
• action
• date
• span
• xmi

The most used subform is the text subform (sf_txt) which can display any number of text-type fields for each module.