https://ark.lparchaeology.com/wiki/api.php?action=feedcontributions&user=152.78.202.165&feedformat=atomARK - User contributions [en]2024-03-29T15:07:25ZUser contributionsMediaWiki 1.27.1https://ark.lparchaeology.com/wiki/index.php?title=Key_Administration_Concepts&diff=391Key Administration Concepts2007-11-20T09:17:23Z<p>152.78.202.165: /* Views */</p>
<hr />
<div>For a more generalised overview of ARK, check out the [http://ark.lparchaeology.com/about about] section of the website. This is a review of concepts that are key for administering an ARK instance effectively.<br />
<br />
==Settings Files==<br />
<br />
ARK is setup by means of plain text files. In order to configure ARK you need to edit these files using a text editor. The files are described briefly below. More detailed developer level documentation is available describing every directive found in the files. For most administrators a brief overview should be sufficient.<br />
<br />
===env_settings.php===<br />
<br />
This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.<br />
<br />
===settings.php===<br />
<br />
This is the main ARK settings file and contains settings relating to the entire instance of ARK.<br />
<br />
===vd_settings.php===<br />
<br />
This contains the validation rules. (See below).<br />
<br />
===field_settings.php===<br />
<br />
This contains the settings directives for fields. (See below).<br />
<br />
===mod_settings.php===<br />
<br />
These files contain settings for each installed module. Each module requires<br />
<br />
==Forms Overview==<br />
<br />
A more detailed explanation of items and fragments can be found in the [http://ark.lparchaeology.com/about about] section of the website. Items are effectively key records. These are the records that the end users will recognise as a 'record'. Items are effectively just an index system, the data that make up the record is contained in fragments that are attached to the items in many ways. Fragments are therefore, in effect, the atomic particles of ARK, they are the smallest unit of data that the system can handle. Fields are a way of describing each fragment within ARK. This differs slightly from the normal database use of the term. In ARK the field is more like a unit of settings which describe the data that may be contained within the field. These data are fragments.<br />
<br />
===Validation Rules===<br />
<br />
Validation rules are the things which make up one of the main components of a field. These could be described as the sub-atomic particles of an ARK fragment, although in fact, they refer to the field not the fragments.<br />
<br />
Validation rules for ARK's forms are contained in the vd_settings.php file. This helps to keep them together. In short, validation rules serve two purposes:<br />
<br />
#They tell a given element of a field how to request itself from the system when it is involved in any kind of form edit routine.<br />
#They tell the update script how to validate that particular element of a fragment.<br />
<br />
Unfortunately these are the hardest of the three main elements of forms to understand and yet they are the most essential. ARK comes with preconfigured validation rules for all the dataclasses and you should be able to make use of these rules in most cases.<br />
<br />
The main exception to this rule is in the case of a custom validation for particular fields as used within a module and especially when we want to force a var to a certain manual value. This can be accomplished by using in-line syntax as documented within the mod_settings files.<br />
<br />
===Fields===<br />
<br />
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.<br />
<br />
===Subforms===<br />
<br />
[[Subforms]] are made up of settings directives which describe units within forms that are visible to end users. Typically they contain a list of fields to display. The fields already know how to display and validate themselves when used within a form, so the subform is relatively easy to set up.<br />
<br />
==Views==<br />
ARK consists of different views<br />
<br />
===Data Entry===<br />
The Data Entry view allows the users to enter the data through to main forms: registration and data entry forms. Furthermore, an administrator can add their own data entry forms. <br />
<br />
===Data View=== <br />
This view is used for fintering the data and displaying it as lists or tables with the functionallity of exporting the lists. <br />
<br />
===Micro View===<br />
These pages provide a more compact view of the data in the different modules and can also be used to present data which have been input through other means like spatial features. <br />
<br />
===Map View===<br />
The Map View is used to display the spatial features of the ARK project. <br />
[[category: Administrator]]</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Key_Administration_Concepts&diff=185Key Administration Concepts2007-11-20T09:12:08Z<p>152.78.202.165: </p>
<hr />
<div>For a more generalised overview of ARK, check out the [http://ark.lparchaeology.com/about about] section of the website. This is a review of concepts that are key for administering an ARK instance effectively.<br />
<br />
==Settings Files==<br />
<br />
ARK is setup by means of plain text files. In order to configure ARK you need to edit these files using a text editor. The files are described briefly below. More detailed developer level documentation is available describing every directive found in the files. For most administrators a brief overview should be sufficient.<br />
<br />
===env_settings.php===<br />
<br />
This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.<br />
<br />
===settings.php===<br />
<br />
This is the main ARK settings file and contains settings relating to the entire instance of ARK.<br />
<br />
===vd_settings.php===<br />
<br />
This contains the validation rules. (See below).<br />
<br />
===field_settings.php===<br />
<br />
This contains the settings directives for fields. (See below).<br />
<br />
===mod_settings.php===<br />
<br />
These files contain settings for each installed module. Each module requires<br />
<br />
==Forms Overview==<br />
<br />
A more detailed explanation of items and fragments can be found in the [http://ark.lparchaeology.com/about about] section of the website. Items are effectively key records. These are the records that the end users will recognise as a 'record'. Items are effectively just an index system, the data that make up the record is contained in fragments that are attached to the items in many ways. Fragments are therefore, in effect, the atomic particles of ARK, they are the smallest unit of data that the system can handle. Fields are a way of describing each fragment within ARK. This differs slightly from the normal database use of the term. In ARK the field is more like a unit of settings which describe the data that may be contained within the field. These data are fragments.<br />
<br />
===Validation Rules===<br />
<br />
Validation rules are the things which make up one of the main components of a field. These could be described as the sub-atomic particles of an ARK fragment, although in fact, they refer to the field not the fragments.<br />
<br />
Validation rules for ARK's forms are contained in the vd_settings.php file. This helps to keep them together. In short, validation rules serve two purposes:<br />
<br />
#They tell a given element of a field how to request itself from the system when it is involved in any kind of form edit routine.<br />
#They tell the update script how to validate that particular element of a fragment.<br />
<br />
Unfortunately these are the hardest of the three main elements of forms to understand and yet they are the most essential. ARK comes with preconfigured validation rules for all the dataclasses and you should be able to make use of these rules in most cases.<br />
<br />
The main exception to this rule is in the case of a custom validation for particular fields as used within a module and especially when we want to force a var to a certain manual value. This can be accomplished by using in-line syntax as documented within the mod_settings files.<br />
<br />
===Fields===<br />
<br />
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.<br />
<br />
===Subforms===<br />
<br />
[[Subforms]] are made up of settings directives which describe units within forms that are visible to end users. Typically they contain a list of fields to display. The fields already know how to display and validate themselves when used within a form, so the subform is relatively easy to set up.<br />
<br />
==Views==<br />
<br />
<br />
[[category: Administrator]]</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Key_Administration_Concepts&diff=184Key Administration Concepts2007-11-20T08:33:16Z<p>152.78.202.165: </p>
<hr />
<div>For a more generalised overview of ARK, check out the [http://ark.lparchaeology.com/about about] section of the website. This is a review of concepts that are key for administering an ARK instance effectively.<br />
<br />
==Settings Files==<br />
<br />
ARK is setup by means of plain text files. In order to configure ARK you need to edit these files using a text editor. The files are described briefly below. More detailed developer level documentation is available describing every directive found in the files. For most administrators a brief overview should be sufficient.<br />
<br />
===env_settings.php===<br />
<br />
This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.<br />
<br />
===settings.php===<br />
<br />
This is the main ARK settings file and contains settings relating to the entire instance of ARK.<br />
<br />
===vd_settings.php===<br />
<br />
This contains the validation rules. (See below).<br />
<br />
===field_settings.php===<br />
<br />
This contains the settings directives for fields. (See below).<br />
<br />
===mod_settings.php===<br />
<br />
These files contain settings for each installed module. Each module requires<br />
<br />
==Forms Overview==<br />
<br />
A more detailed explanation of items and fragments can be found in the [http://ark.lparchaeology.com/about about] section of the website. Items are effectively key records. These are the records that the end users will recognise as a 'record'. Items are effectively just an index system, the data that make up the record is contained in fragments that are attached to the items in many ways. Fragments are therefore, in effect, the atomic particles of ARK, they are the smallest unit of data that the system can handle. Fields are a way of describing each fragment within ARK. This differs slightly from the normal database use of the term. In ARK the field is more like a unit of settings which describe the data that may be contained within the field. These data are fragments.<br />
<br />
===Validation Rules===<br />
<br />
Validation rules are the things which make up one of the main components of a field. These could be described as the sub-atomic particles of an ARK fragment, although in fact, they refer to the field not the fragments.<br />
<br />
Validation rules for ARK's forms are contained in the vd_settings.php file. This helps to keep them together. In short, validation rules serve two purposes:<br />
<br />
#They tell a given element of a field how to request itself from the system when it is involved in any kind of form edit routine.<br />
#They tell the update script how to validate that particular element of a fragment.<br />
<br />
Unfortunately these are the hardest of the three main elements of forms to understand and yet they are the most essential. ARK comes with preconfigured validation rules for all the dataclasses and you should be able to make use of these rules in most cases.<br />
<br />
The main exception to this rule is in the case of a custom validation for particular fields as used within a module and especially when we want to force a var to a certain manual value. This can be accomplished by using in-line syntax as documented within the mod_settings files.<br />
<br />
===Fields===<br />
<br />
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.<br />
<br />
===Subforms===<br />
<br />
[[Subforms]] are made up of settings directives which describe units within forms that are visible to end users. Typically they contain a list of fields to display. The fields already know how to display and validate themselves when used within a form, so the subform is relatively easy to set up.<br />
<br />
<br />
[[category: Administrator]]</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Administrator_Manual&diff=212Administrator Manual2007-11-20T08:30:56Z<p>152.78.202.165: </p>
<hr />
<div>The administrator manual is aimed at people who are downloading and installing ARK. If you are struggling with installation or administration, you should consider contacting the ARK team to buy a preconfigured ARK. This would help support the project and make a contribution towards the ongoing development of the project.<br />
<br />
[[Key Administration Concepts]]<br />
<br />
[[Installation]]<br />
<br />
[[Initial setup]]<br />
<br />
[[Detailed setup of ARK]]<br />
<br />
[[User Administration]]<br />
<br />
[[Subforms]]<br />
<br />
[[category: Administrator]]</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=386Initial setup2007-11-20T07:38:25Z<p>152.78.202.165: /* What subforms do you want? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 Class|data classes]]<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subforms|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.<br />
<br />
=====Simple one data class subforms=====<br />
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. <br />
<br />
=====Combined data class subforms=====<br />
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 [[Chains|chained]] to a date and an action.<br />
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.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=175Initial setup2007-11-20T07:34:33Z<p>152.78.202.165: /* What subforms do you want? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 Class|data classes]]<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|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.<br />
<br />
=====Simple one data class subforms=====<br />
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. <br />
<br />
=====Combined data class subforms=====<br />
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 [[Chains|chained]] to a date and an action.<br />
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.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Data_Class&diff=2066Data Class2007-11-20T07:33:28Z<p>152.78.202.165: </p>
<hr />
<div>Data Classes are the broad categories of data held in ARK. The data is divided by its nature rather than by its meaning. This is significant in that different classes of data require different handling in forms and the database. The classes of data supported by ARK are:<br />
<br />
* Text - generally long-text<br />
* Attributes - this requires an attribute type like a materials inventory where the attributes can be brick, coin or glass.<br />
* Dates<br />
* Actions - somebody doing something, is often combined with a person from the address book<br />
* Spans - a span from for example a date to the next (e.g. 100BC-AD250)<br />
* Numbers<br />
* Polygons<br />
* Lines<br />
* Points<br />
* XMI - a link between two module items<br />
<br />
<br />
[[Category:Glossary]]</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=174Initial setup2007-11-20T07:32:08Z<p>152.78.202.165: /* What do you want to record? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 Class|data classes]]<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the seven different field types depending on the outcome.<br />
<br />
=====Simple one data-type subforms=====<br />
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. <br />
<br />
=====Combined data-type subforms=====<br />
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 [[Chains|chained]] to a date and an action.<br />
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.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=172Initial setup2007-11-20T07:31:29Z<p>152.78.202.165: /* What do you want to record? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 [[Dataclass|data classes]]<br />
<br />
=====Field data-types=====<br />
<br />
*txt - generally long-text<br />
*number - all numbers<br />
*attribute - this requires an attribute type like a materials inventory where the attributes can be brick, coin or glass. <br />
*action - somebodyt doing something, is often combined with a person from the address book<br />
*date - any date<br />
*span - a span from for example a date to the next (e.g. 100BC-AD250)<br />
*xmi - a link between two module items<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the seven different field types depending on the outcome.<br />
<br />
=====Simple one data-type subforms=====<br />
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. <br />
<br />
=====Combined data-type subforms=====<br />
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 [[Chains|chained]] to a date and an action.<br />
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.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Chains&diff=2083Chains2007-11-20T07:29:57Z<p>152.78.202.165: </p>
<hr />
<div>Chains are used in the database when you want a field to be attached to another field instead of an item. An example is the interpretation subform which contains a piece of text, a date and an action. The text-type 'interpretation' will be attached to the item and the date and action will be attached to the piece of text. ('''ADD a nice model of this''')<br />
[[Category:Glossary]]</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=171Initial setup2007-11-20T07:11:52Z<p>152.78.202.165: /* Combined data-type subforms */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 one of the seven field types below.<br />
<br />
=====Field data-types=====<br />
<br />
*txt - generally long-text<br />
*number - all numbers<br />
*attribute - this requires an attribute type like a materials inventory where the attributes can be brick, coin or glass. <br />
*action - somebodyt doing something, is often combined with a person from the address book<br />
*date - any date<br />
*span - a span from for example a date to the next (e.g. 100BC-AD250)<br />
*xmi - a link between two module items<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the seven different field types depending on the outcome.<br />
<br />
=====Simple one data-type subforms=====<br />
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. <br />
<br />
=====Combined data-type subforms=====<br />
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 [[Chains|chained]] to a date and an action.<br />
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.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Chains&diff=170Chains2007-11-20T07:09:37Z<p>152.78.202.165: </p>
<hr />
<div>Chains are used in the database when you want a field to be attached to another field instead of an item. An example is the interpretation subform which contains a piece of text, a date and an action. The text-type 'interpretation' will be attached to the item and the date and action will be attached to the piece of text. ('''ADD a nice model of this''')</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Chains&diff=168Chains2007-11-20T07:08:47Z<p>152.78.202.165: /*Chains*/</p>
<hr />
<div>Chains are used in the database when you want a field to be attached to another field instead of an item. An example is the interpretation subform which contains a piece of text, a date and an action. The text-type 'interpretation' will be attached to the item and the date and action will be attached to the piece of text. ((( ADD a nice model of this )))</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=169Initial setup2007-11-20T07:05:31Z<p>152.78.202.165: /* What subforms do you want? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 one of the seven field types below.<br />
<br />
=====Field data-types=====<br />
<br />
*txt - generally long-text<br />
*number - all numbers<br />
*attribute - this requires an attribute type like a materials inventory where the attributes can be brick, coin or glass. <br />
*action - somebodyt doing something, is often combined with a person from the address book<br />
*date - any date<br />
*span - a span from for example a date to the next (e.g. 100BC-AD250)<br />
*xmi - a link between two module items<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the seven different field types depending on the outcome.<br />
<br />
=====Simple one data-type subforms=====<br />
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. <br />
<br />
=====Combined data-type subforms=====<br />
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 [[Chains|chained]] to a date and an action.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=167Initial setup2007-11-20T06:47:49Z<p>152.78.202.165: /* What do you want to record? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 one of the seven field types below.<br />
<br />
=====Field data-types=====<br />
<br />
*txt - generally long-text<br />
*number - all numbers<br />
*attribute - this requires an attribute type like a materials inventory where the attributes can be brick, coin or glass. <br />
*action - somebodyt doing something, is often combined with a person from the address book<br />
*date - any date<br />
*span - a span from for example a date to the next (e.g. 100BC-AD250)<br />
*xmi - a link between two module items<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the seven different field types depending on the outcome.<br />
<br />
=====Text subform (sf_txt)=====<br />
The most used subform is the text subform (sf_txt) which can display any number of text-type fields for each module.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=166Initial setup2007-11-20T06:47:33Z<p>152.78.202.165: /* What do you want to record? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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 one of the seven field types below.<br />
<br />
<br />
=====Field data-types=====<br />
<br />
*txt - generally long-text<br />
*number - all numbers<br />
*attribute - this requires an attribute type like a materials inventory where the attributes can be brick, coin or glass. <br />
*action - somebodyt doing something, is often combined with a person from the address book<br />
*date - any date<br />
*span - a span from for example a date to the next (e.g. 100BC-AD250)<br />
*xmi - a link between two module items<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the seven different field types depending on the outcome.<br />
<br />
=====Text subform (sf_txt)=====<br />
The most used subform is the text subform (sf_txt) which can display any number of text-type fields for each module.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=165Initial setup2007-11-20T06:46:18Z<p>152.78.202.165: /* What subforms do you want? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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.<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the seven different field types depending on the outcome.<br />
<br />
=====Text subform (sf_txt)=====<br />
The most used subform is the text subform (sf_txt) which can display any number of text-type fields for each module.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=164Initial setup2007-11-20T06:45:33Z<p>152.78.202.165: /* Data-types */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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.<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|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.<br />
<br />
=====Data-types=====<br />
<br />
*txt - generally long-text<br />
*number - all numbers<br />
*attribute - this requires an attribute type like a materials inventory where the attributes can be brick, coin or glass. <br />
*action - somebodyt doing something, is often combined with a person from the address book<br />
*date - any date<br />
*span - a span from for example a date to the next (e.g. 100BC-AD250)<br />
*xmi - a link between two module items<br />
<br />
=====Text subform (sf_txt)=====<br />
The most used subform is the text subform (sf_txt) which can display any number of text-type fields for each module.</div>152.78.202.165https://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=163Initial setup2007-11-20T06:39:54Z<p>152.78.202.165: /* What subforms do you want? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
====A Name==== <br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
====What do you want to record?====<br />
<br />
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. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|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.). <br />
<br />
<br />
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.<br />
<br />
====What subforms do you want?====<br />
<br />
ARK comes packaged with a number of different [[Subform|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.<br />
<br />
=====Data-types=====<br />
<br />
*txt<br />
*number<br />
*attribute<br />
*action<br />
*date<br />
*span<br />
*xmi<br />
<br />
The most used subform is the text subform (sf_txt) which can display any number of text-type fields for each module.</div>152.78.202.165