Design of a Generic Metamodel forFieldwork Data Management

Aisel GharedaghliFebruary, 2003

Design of a Generic Metamodel forFieldwork Data Management

By

Aisel Gharehdaghli

Thesis submitted to the International Institute for Geo-information Scienceand Earth Observation in partial fulfilment of the requirements for the degreeof Master of Science in Geoinformatics

Degree Assessment Board :

Prof. Dr. M.J. Kraak - ChairmanProf. Dr. M.J. Kraak - External ExaminerDr. Ir. R.A. de By - 1st SupervisorDr. E.M. Schetselaar - 2nd SupervisorDr. M. Sharif - MemberDr. H. Ebadi - Member

INTERNATIONAL INSTITUTE FOR GEO-INFORMATION SCIENCE ANDEARTH OBSERVATION ENSCHEDE, THE NETHERLANDS

1

Disclaimer

This document describes work undertaken as part of a programmeof study at the International Institute for Geo-information Scienceand Earth Observation. All views and opinions expressed thereinremain the sole responsibility of the author, and do not necessarilyrepresent those of the institute.

2

Abstract The core part of geoscience information system is field

data. A well-structured database schema for storing field data can help toeffectively organize and disseminate geoscientific knowledge. This study wasan attempt to find a generic and systematic way for managing geoscientificfieldwork data. A metamodel (reference model) was designed. The compo-nents of the metamodel are the metaconcepts, which are the most generalconcepts used in geoscientific fieldwork. The metaconcepts were describedand the relationships among them were explained. In design of the meta-model, classification mechanism of acquired knowledge is considered, whichcan help to manage the interpreted and inferred information.Different kinds of data models can be instantiated from the metamodel. Spec-ifications, rules, and required steps of instantiation method were discussed.Instantiation of object types and their relationships in derived databaseschemas can have different cases, which should be considered in the usedmethod.

Keywords: Field data, Metamodel, Database schema derivation, In-stantiation method.

3

Acknowledgments

I would like to thank, Dr. Ir. R. de By, my first supervisor for his valuableguidance and comments, and also to thank Dr. E. M. Schetselaar, my secondsupervisor, for his helpful discussions about the subject of thesis.Thanks to ITC, JIK, AREEO that makes it possible for me to do this work.Thanks to my classmates in GFM group for their friendship and moralities.Special thanks to my family for their support, patience and kindness.

4

Contents

1 Introduction 91.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Research questions . . . . . . . . . . . . . . . . . . . . . . . . 101.4 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.6 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . 12

2 Literature review 142.1 Geoscientific field data . . . . . . . . . . . . . . . . . . . . . . 142.2 Prior work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Geoscientific database schema . . . . . . . . . . . . . . . . . . 172.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 A Fieldwork Metamodel 213.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Geoscientific Fieldwork Metamodel . . . . . . . . . . . . . . . 223.3 Definitions and relations . . . . . . . . . . . . . . . . . . . . . 233.4 Interpreted Information . . . . . . . . . . . . . . . . . . . . . . 273.5 A geologic fieldwork data model . . . . . . . . . . . . . . . . . 283.6 A soil survey and its data model . . . . . . . . . . . . . . . . . 29

4 Database schema derivation from the metamodel 324.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Specifications of the method for database schema derivation . 334.3 Instantiation Method . . . . . . . . . . . . . . . . . . . . . . . 344.4 Instantiation of database schema elements . . . . . . . . . . . 40

5 Conclusions and Recommendations 435.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5

5.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 45

6

List of Figures

2.1 The underlying data model of Fieldlog . . . . . . . . . . . . . 162.2 Fieldlog ’s layered architecture . . . . . . . . . . . . . . . . . . 182.3 Relationship between concept, class and occurrence . . . . . . 19

3.1 A general representation of a metamodel and one of its models 223.2 A metamodel for geoscientific fieldwork . . . . . . . . . . . . . 243.3 A typical geologic fieldwork data model . . . . . . . . . . . . . 293.4 A typical soil survey data model . . . . . . . . . . . . . . . . . 31

4.1 The case of instantiation when both A and B have one instancetype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 The case of instantiation when metaconcept A has one instancetype and B has two instance types . . . . . . . . . . . . . . . 36

4.3 The case of instantiation when both metaconcepts A and Bhave more than one members . . . . . . . . . . . . . . . . . . 38

4.4 Different types of cardinality constraint for 3 case of relation-ship instantiation . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Instantiation of Project and Area of Observation relationship . 41

7

List of Tables

3.1 Relations between geologic data model’s object types and Baseobject types of the metamodel . . . . . . . . . . . . . . . . . . 30

3.2 Relations between soil survey data model’s object types andBase object types of the metamodel . . . . . . . . . . . . . . . 31

4.1 Grouping of metaconcepts based on their number of instancetypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8

Chapter 1

Introduction

1.1 Background

Field data is the essential product of geoscientific fieldwork. A large numberof highly efficient databases exist, but most of them have been developed fora specific purpose and are thus mono-disciplinary.

For field data acquisition, different techniques and methods are used, butonly part of the acquired knowledge is represented in a (spatial) database.Geoscientific data are used in many disciplines: land management decision-making, engineering design, search for mineral resources, ground water ex-ploration, etc (Woldai and Schetselaar, 2002).

A geoscience information system should be based on a flexible data modelto include wide range of earth science disciplines and can be used by differentkinds of user. Because of the dynamic nature of geoscience processes, e.g.,natural hazards like landslide and also new explorations and new or revisedtheories, the underlying data model of the information system should be easyto adapt to these changes (Richard, 1999). A fieldwork data managementsystem should have capabilities for determining geographic position, on-sitedata recording, managing observations and also for manipulating and facili-tating the interpretations (Brodaric, 1997).

1.2 Problem definition

Designing a generic field data management system requires a conceptual un-derstanding of fieldwork independently from its domain. The most commonentity types in geoscience should be identified and the relationships among

9

them should be defined.Because of the complexity of field systems, most of the observations are

done in a subjective manner, as structure and content of databases vary fromone geoscientist to another even within one discipline.

For designing a conceptual model, two approaches can be used: ‘top-down’ and ‘bottom-up’ (Broome, et al, 1993). In a ‘top-down’ approach,the range of concepts is limited and fieldworkers must work with predefinedconcepts and structures. This approach is not suitable for geoscientific workbecause it is problematic for fieldworkers when they want to record and storenew findings or new interpretations that were not considered at the designstage (Chew, 1995). A geoscientist’s working environment is an open systemand they encounter a variety of geographical and environmental situations.So, they need a structurally flexible system for data collection without in-herent restriction on the content and method for field data acquisition. Forachieving this goal, a ‘bottom-up’ approach is more suitable. This meansthat fieldworkers don’t have to use a dictated model. A prerequisite of usinga ‘bottom-up’ approach is to find a generic and systematic way in whichgeoscientists can create their own specific database individually.

The problem in designing a generic model for geoscientific fieldwork isthat, acquired data are not simple observed facts, they are interpretationsand inferences that observers make based on the discipline specific theoryand their cognition level. The meaning and definition of specified featuresand their relationships are discipline specific and may also differ from oneobserver to the other one. So, features can have multiple descriptions. Afield data management system requires a flexible structure so that can offerfacility to store and retrieve not only observed and measured data, but alsointerpretative and inferred information.

The other problem is about terminology used in geoscientific fieldwork.The terms used for indicating the features may be not clarified or semanti-cally ambiguous. Terms may have multiple meanings or one feature may havemultiple names. Systems based on fixed or static structure can not be usefulfor organizing and managing geoscientific field data, which are complex anddynamic in nature (Brodaric, 2000).

1.3 Research questions

For designing a generic metamodel for fieldwork data management, with aflexible structure independent from disciplines in the geoscience domain, thecomponents of the metamodel should be identified. In this case, the compo-

10

nents are the most common concepts used in geoscientific fieldwork. Thenthe relationships among them should be found. The next step is to describethe specifications of a method that can be used for database schema deriva-tion from the metamodel.

In this study an attempt is made to find answers to the following ques-tions:

• What could be a generic and systematic way for organizing geosciencefieldwork databases?

• What are the components of the metamodel for geoscientific fieldworkdata management and what types of relationships exist between them?

• Is there a trustworthy method of allowing geoscientists to design theirown fieldwork databases?

• How can this method be used by geoscientists from different disciplinesand with different levels of expertise?

1.4 Objectives

The objectives of this study are as follows:

• To find the metaconcepts used in geoscientific fieldwork, and to usethem as the components of the metamodel.There is a main commonal-ity in different disciplines of geoscience, and that is the Earth’s materi-als. Geoscientists study the Earth’s materials from their specializationviewpoints. Generalizing the common concepts of different disciplinesand organizing them in a generic metamodel can be a systematic wayfor geoscientific fieldwork data management.

• To describe the metaconcepts and to explain the relationships existingamong them. For designing a model, its components and their relation-ships with each other should be identified. It should be clarified whatthe meaning of each component is, and why it is used in the model.

11

• To design a typical fieldwork data model in geology and in soil science asexamples of application of the metamodel, to represent the relationshipsbetween the elements of data model and the metamodel.

• To describe specifications of a method for instantiating a databaseschema from the metamodel.The aim of designing a generic model isto provide a method for geoscientists, such that they can create theirown specific fieldwork databases.

1.5 Methodology

Before designing the conceptual model, a requirement analysis has to be per-formed. The right type of objects, in this case base object types (metacon-cepts) should be determined. Their descriptions, attributes and associationsshould be identified. Then, the results can be expressed as a model. Becausemetaconcepts are going to be used, the result is a metamodel from whichmodels can be instantiated.

For achieving the above mentioned objectives, the following steps need tobe done:

• Literature review about prior work which has been done for managinggeoscientific field data, and also for better understanding the nature ofacquired data in fieldwork.

• Identification of the most common concepts used in fieldwork of dif-ferent geoscience disciplines, determining the components of the meta-model, which can be called metaconcepts or base object types.

• Design of a metamodel based on the identified metaconcepts; represen-tation of the metamodel by using a modelling language.

• Describing the specifications of a method for database schema deriva-tion and explaining the rules of instantiation from the metamodels.

1.6 Structure of the thesis

The contents of this thesis are organized as follows:Chapter one provides background to the purpose of the thesis, problem def-

12

inition, research questions, objectives, methodology and the structure of thethesis. A brief introduction to the nature of geoscientific field data is includedin the first section of chapter two. Next Fieldlog as a field data capture toolused in geologic fieldwork is discussed. In the next part of this chapter, thespecifications of geoscientific database schema is discussed. General speci-fications of database schema elements in geoscience are summarized in thelast part of chapter two. Chapter three provides an introduction to whata metamodel is, then a metamodel for geoscientific fieldwork is represented.In the next section of this chapter, the components of the metamodel andtheir relationships are described. The relation between metamodel and in-terpretative and inferred information is discussed in the next section of thischapter. The last two sections of this chapter provide descriptions of a typicalgeologic fieldwork model and a soil survey data model, respectively. In chap-ter four, database schema derivation from the metamodel will be discussed.The specifications and steps of the method for database schema derivationfrom the metamodel will be described in this chapter. Chapter five includesconclusions and recommendations for complementary work.

13

Chapter 2

Literature review

2.1 Geoscientific field data

The core part of a geoscientific information system is the field data. In-creasingly, new technologies are used in field data capture, storage and datamanagement. Appropriate usage of these technologies and design of a well-structured database for geoscientific field data can help to effectively organizeand disseminate geoscientific knowledge. This knowledge is mostly derivedfrom the geoscientists’ understanding of the Earth’s materials and processes.The source of this knowledge is data captured during fieldwork. Field data ac-quisition can be done by sampling from the Earth’s material, by direct humanobservations, using field-based instruments and remote sensing techniques.The geographical and environmental condition, purpose of the project andexpertise of worker are the factors that influence the method(s) used in afieldwork.

In geoscience, descriptive specifications of phenomena are not constant.Descriptions may change in time due to physical changes of a feature as a re-sult of natural processes, or due to increased knowledge and understandingsof geoscientists from the phenomena. A specific feature may have variousdescriptions as the result of multiple interpretations made by different ob-servers. Interpretations and inferences are the result of applied scientifictheory and thinking process of observers about a feature.

Acquired data about environmental concepts may be directly observedor measured, they are interpretations of geoscientists from a phenomena, orinferences about historical processes. So system used for managing such data

14

should consider the variability and complexity of them.

2.2 Prior work

Fieldlog is one of the first field data capture software tools developed by theGeological Survey of Canada (GSC), for digital management of geologic fielddata and geologic map construction. It is a multi-functional system, capa-ble of converting spatial database fields to map-graphics in AutoCAD .dxfinterchange format (Schetselaar, 1995).

Fieldlog can be run through AutoCAD, which supports its cartographicfunctionality; also project-specific field data can be stored in defined databasesby using Fieldlog ’s specific interface within AutoCAD. The data entry canbe done directly in the field by using a portable computer, but field data canalso be imported from a PDA (Personal Digital Assistant) handheld com-puter, such as the Apple Newton. Data captured using GPS receivers canbe imported directly as tables in delimited format.

To start working with Fieldlog, a map of the study area must be openedwithin AutoCAD as a drawing, then by using the underlying database struc-ture of Fieldlog, geological field data related to the map can be stored.

Fieldlog maintains a relational database for storing field observations. Itis founded on a conceptual data model that consists of common geologicconcepts and the relationships that exist among them. These common con-cepts can be refined or adapted by geologists to define their project-specificdatabase definitions. The underlying data model of Fieldlog is shown inFigure 2.1.

This model consists of 15 common geologic concepts. Outcrop and Stationare the concepts for representing the geographic locations, where observationsmade. More than one station may occur within one outcrop, Traverse refersto a travelled path that observations made along it. One traverse crossesmore than one outcrop or station. Segment refers to further spatial parti-tion, often vertical, of outcrop or station. More than one segment may bepartitioned in one outcrop or station. Rock refers to the discipline specifictheme that the other non-spatial concepts are used for describing it. Com-position refers to the internal constituents of rock, and Disposition(Genesis)describes the setting of rock or historical processes that led to formation ofa specific configuration of rock. Samples are taken for describing the compo-sition and disposition of rock and also they can be used for further analysise.g., geochemistry. Boundary, Legend, and Unit are the interpreted conceptsthat can be associated with field observations and can be used to deduce

15

Figure 2.1: The underlying data model of Fieldlog (Brodaric 1997)

them. Three concepts, Dictionary, Reference, and Other are not shown inthe figure. A customizable dictionary for geologic terms is included for main-taining the semantic consistency of the terms used in a project.

Fieldlog works with a relational database, so concepts are translated intorelational database tables for data processing. For describing a field project,a geologist defines a set of tables. Each table is associated to a table type(Brodaric, et al, 2001).

Four levels of abstraction are used in the design of Fieldlog ’s data model:data instances, data classes, ontologic classes, and metaclasses (Figure 2.2).In the first layer, data instances represent observed and interpreted data,for example a particular rock description. In the second layer, data classes

16

represent types of instances such as the class of rock descriptions or the def-inition of the table used for storing the data instances. In the third layer,ontologic classes represent common concepts and rules in geologic field dataand map information. This layer consists of cartographic, geospatial, ge-ologic and metadata classes. The cartographic classes control the geologicmap symbolization. Coordinate processing is controlled by geospatial classes.Constraints that should be considered for geologic field data such as the typesof the relationships and predefined attributes and behaviors are included inthe geologic classes of the ontologic layer. The dotted lines shown in Fig-ure 2.2 represent the relationships between elements of different layers. Forexample, Station is one of the classes of the ontologic layer, i.e. it is one ofthe common concepts or table types in Fieldlog ’s data model. In a project-specific database definition, for storing the observations related to a drillhole, a table associated with ‘Station’ can be created in the data class layer.This will inherit all the predefined properties and relationships of the tabletype ‘Station’ from the ontologic layer. In the last layer, metaclasses are theprimitives or general rules that regulate how classes are created, describedand how they behave. The components of the data model shown in Figure 2.1are the common geologic concepts or the table types included in the geologicclasses of ontologic layer.

The difference between metaclasses and ontologic classes is that meta-classes regulate general rules necessary for organizing the classes but onto-logic classes are specified rules and constraints for the geologic domain. Thetwo layers metaclasses and ontologic classes that are supplied by Fieldlog arefixed, whereas data classes and data instances are created by users (Brodaric,1997).

Fieldlog was developed specifically for geological fieldwork. It keeps thegeologist away from technical details of database construction. Because ofthe similarities among disciplines in geoscience, it can be used in fieldworkof other disciplines, though its usage there is limited. One reason for thislimitation is in the type of common concepts included in its data model, andtheir predefined properties and constraints and interrelationships. They arenot at the appropriate level of generalization to include the most commonconcepts in geoscience.

2.3 Geoscientific database schema

There are two general types of object in the geoscientific fieldwork databaseschema. First, spatial object types that are related to and provide explana-

17

Figure 2.2: Fieldlog ’s layered architecture (from Brodaric, 1997)

tion about some location or part of the Earth. They have spatial character-istics and can exist independently, e.g., survey areas, outcrops. The othertypes of object are non-spatial or descriptive, which are used to categorize,describe or interpret the properties of the former objects, for example, struc-tural measurements in geology. These types of object should be related toone of the objects of the first group (Giles and Bain, 1995).

Data acquired in fieldwork are not just observations but also interpreta-tions, which are often inferred from observed data. The observations relatedto the surface or subsurface of the Earth are interpretations of the infor-mation available at a specific time. Visiting them at another time or visitsby different persons, may lead to new interpretations and new information.Thus, according to the physical situation, cognition of the observer and the

18

scientific hypothesis, different interpretations can be made and a single phe-nomenon can be explained by several models.

Systems based on a fixed or static database schema would be problematicfor managing geoscientific data. For different situations, either the schemashould be adjusted or changed frequently, or the newly acquired data couldnot be stored and managed correctly. One way to have a dynamic geoscien-tific database schema is to found it on an evolving database schema, whichincludes concepts and factors affecting the evolution of concepts.

A concept is an abstract object. A concept represents an entity, action,or state (Sowa, 1984). A concept has intension and extension. Intensionrefers to the essential meaning and properties of a concept. For example,lake is a general concept. It has a relatively fixed definition—a large area ofwater surrounded by land—, and it has properties such as name, size, depth,etc. The objects that possess this meaning can be considered or classified asthe instances of lake. Reasoning about intension depends on logic, not juston observations. A general concept can have subtypes. A subtype inheritsthe intension of the general concept and has additional specific properties,e.g., polluted lake is a subtype of lake. Extension refers to the group of realobjects which provides the typical example of a concept. For lake, all thelakes in the world form its extension. A group of elements which togetherform the members of a concept’s extension is referred as the concept’s class.An occurrence is an individual element that can be placed in a concept’sclass. The determination of the occurrences as the member of the extensionof a concept is done through a process called classification. The classifica-tion mechanism is based on the intension or properties of the concept, i.e.,its attributes, functions, and constraints, which leads to determine wetheran occurrence belongs to a concept or not (Brodaric and Gahegan, 2002).Figure 2.3 shows a schema for illustrating the above defined terms.

Figure 2.3: The schematic illustration for showing the relationship betweenconcept, class and occurrence (modified from Brodaric and Gahegan, 2002)

19

Considering the classification mechanism in data modelling provides away for better management of geoscientific field data, and for establishingrelations between observed data and interpreted or inferred information.

Concepts at high level of abstraction remain relatively fixed. The defini-tion of a general concept, for example lake, is much more stable than thatof a less general concept, e.g., polluted lake. Thus, the database schemafounded on general concepts will remain much more stable than the concep-tual schema developed upon the concepts at lower level of abstraction.

2.4 Summary

The specifications of geoscientific database schema can be summarized asfollows:

• Two general types of object are used in geoscientific database schema:spatial and non-spatial.

• The acquired data are not just observations but also interpretations.Therefore, the factors affecting the scientific reasoning should be con-sidered. Reasoning is affected by: the known theory, the physical situ-ation, the observer’s cognition level.

• Including mechanism for grouping field observations and assigning themto specified classes in a classification reference provides a way for man-aging interpretative and inferred information.

• The general concepts are relatively fixed. The database schema foundedon such concepts will be more stable. The level of concept generaliza-tion should be applicable to the disciplines within geoscience domain.

20

Chapter 3

A Fieldwork Metamodel

3.1 Introduction

Geoscientific environments are open systems and because observations andinterpretations are made in a subjective manner, multiple models can bemade to explain geographical phenomena. These multiple models withina discipline and models of the related disciplines in geoscience, can be or-ganized through abstraction of models at a higher level. A higher level ofabstraction means to pay more attention to essential aspects and to ignoremore details (Blaha and Premerlani, 1998). Figure 3.1 shows the relationsbetween a metamodel, a model and a database schema.

In this study, fieldwork metamodel refers to a generic or reference modelthat different types of geoscientific database schema can be instantiated fromit. By finding the most common concepts (base objects types) in geosciencedisciplines, their relationships and constraints, a generic model for geoscien-tific fieldwork can be organized such that different types of data model canbe extracted from it by geoscientific fieldworkers individually. The refinedmodels are discipline-based or project-based but because they are extractedfrom one generic model they are consistent conceptually and in future canbe merged and shared.

In the next section a fieldwork metamodel is described. UML ( Uni-fied Modelling Language) is used as modelling language for representing themodel. It is the most general model at the highest level of abstraction thatcan be used for designing models in any domain. In (Rumbough, et al, 1999),UML is described as a “general-purpose visual modelling language that is de-signed to specify, visualize, construct and document the artifacts of a softwaresystem.” UML provides and defines meta-meta objects for designing meta-

21

models and models. It contains several types of diagram. In this study, theclass diagram (static diagram) is used for depicting the base object types(metaconcepts) and their relationships.

Figure 3.1: A general representation of a metamodel and one of its models

3.2 Geoscientific Fieldwork Metamodel

A metamodel for geoscientific fieldwork is shown in Figure 3.2. This modelconsists of the elements (base objects types) that are abstracts of the mostcommon concepts used in fieldwork of different disciplines in geoscience (ge-ology, soil science, geomorphology). It is assumed that the components (baseobjects types) of this model cover (include) all possible elements that can beused in the fieldwork database schema of different disciplines in geoscience.In other words, the refined database schema can not have an element that isnot instantiated from one of the base objects types. Each element or objecttype of the extracted schema must be an instance of only one base objecttype, but instantiation of more than one object type from one base object

22

type is possible. Instantiating all of the base object types is not necessary,i.e., all of them may not have instance(s) in refined schema. For example in aspecific fieldwork, based on the nature of study, there may be no object typerelated to the section. The design of the metamodel should be in such a waythat the consistency of the model remains when base object types have noinstance in the extracted schema. The object types of the database schemacan be considered as the subtypes of base object types, so they will inheritall properties and constraints of their parent object types.

In order to instantiate a correct and desired database schema from themetamodel, the definitions and properties of the base object types should beknown to the users. It should be clarified, what each base object type is, andwhat constraints it has, and for what types of object it can be used. In thenext section, the base object types of the metamodel shown in Figure 3.2 aredescribed.

3.3 Definitions and relations

Project: This base object type refers to general information about fieldwork,like purpose of study, personnel, date, and organization. A geoscientific field-work may be done as a part of project at local, national, or international levelwith contribution of single or multiple organizations. Based on the purposeof study, it may cover a small part of the Earth or a big area. Geoscientificprojects can be single-discipline or multi-discipline with short-time or long-time (many years) duration. A single project may contain several areas ofinterest, and also more than one project may be done on the same study area.So, the relation between base object types, Project and Area of observation ismany to many.

Area of Observation: This base object type is used in the metamodel fordescribing (representing) the study area of fieldwork. In some cases, the areamay be derived from a base map, e.g., digitized from aerial photographs,topographic maps or satellite imagery . Positioning of area of observation isdiscipline-based or project-based. In some cases like geomorphological stud-ies, the positioning of the study area may not be necessary. In soil scienceor geological studies, one positioning may be enough. When the extractionof a map unit is required, more than one positioning should be obtained.

Theme: This base object type refers to the discipline of a fieldwork, e.g.,

23

Figure 3.2: A metamodel for geoscientific fieldwork

geology, soil science, geomorphology. In one discipline, there can be branchesor sub-disciplines, for example, structural geology. In one area of observationmultiple projects may be done. These projects may or may not have samediscipline, i.e., a single project can be multi-discipline. But, since objecttypes used for one discipline differ from the object types of the other, so eachderived database schema should be for one main discipline and can have morethan one sub-discipline, at the same time multiple database schemas relatedto one project can have some common object types.

Segment: In geoscientific fieldwork, a segment can be defined as discipline-specific part of the study area, which is accessible to the observer to record

24

information, or it is a part that the fieldworker on the basis of aims of thestudy can differentiate in the study area. The scale of the work, purpose ofthe project, complexity of the geographical condition, and detection of theobserver can be factors influencing the segmentation of the study area. Insome cases, the whole area may be considered as a single segment, in thiscase the area of observation and segment will coincide. Partitioning of thestudy area into segments is discipline-based and could also be project-basedwithin a discipline. An outcrop in a geological fieldwork data model and asoil profile in a soil survey data model are examples of this metaconcept. Asegment may be subdivided into more specific parts, based on the purpose ofthe study or decision of the observer. The identification of subsegments andtheir borderlines may change from one observer to the other. Each segmenttype should be related to one area of observation, an area of observation maycontain multiple segment types.

Site: Site is a base object type used in the metamodel for defining thegeographical location in which segment(s) occur. The number of sites orpositioning measurements in an area of observation should be at least one.Each site type should have association with one area of observation. Onesegment type should have association with one site type, but multiple seg-ments may be in one site.

Route: This is a base object type used for describing the path along whichobservations are made. It can be considered as a series of observation posi-tions. In some cases, having an instance type from this type of base object, forexample traverse in geologic fieldwork, is used for representing the progressof work in the field through determining the number of positions per specifiedperiod of time, and also it shows the density of observation positions in thefield. The density depends on the purpose of the study (e.g. reconnaissance,regional, or detailed mapping), and also on the visibility of area (Barens,1995). There should be at least two observation positions for defining apath. So, the base object type Route should have association with at leasttwo sites. Route type can have association with one area of observation. Inone area of observation none or multiple route may be defined.

Section: In our fieldwork metamodel a section is considered as a base ob-ject type for defining spatial arrangement of sampled points in a segmentor sub-segment, where observations and measurements were acquired. In asegment, an arrangement for the sampled points may or may not be defined.

25

so, the segment type can have association with none or multiple sections, asection type can have association with only one segment or sub-segment.

Sample: In the Oxford dictionary sample is defined as “one of a number ofthings, or parts, or parts of a whole, that can be looked at to see what the restis like.” In geoscientific fieldwork, sample can be part(s) of a segment or sub-segment, i.e., a sample is not necessarily removed from the study area, or itcan be a removed pieces of these. Based on the nature of sample and decisionof observer, it may be sub-sampled. As mentioned, in a fieldwork Sectiontype can be defined through arrangement of a series of sample points, so thebase object type Section should have association with at least two samples.Sample type should have association with only one section. It may happenthat in a fieldwork, Section type is not defined, then Sample type will haveassociation directly with only one segment or one sub-segment. One segmentor one sub-segment may have multiple samples. This case will be discussedin chapter four (instantiation method) later.

In Situ Observation/Measurement: Acquired field data including quali-tative and quantitative descriptions and measurements can be generalized asa base object type, so-called the In Situ Observation/Measurement. Differ-ent aspects of the Earth’s materials can be described through observationsand measurements made in the field directly on the features or via samples.They are used to describe and to interpret the Earth’s materials at differentrange of size, from description of a grain size in a sample to describe thegeneral arrangement or relative position of rock masses of an area (Batesand Jackson, 1987). Multiple object types can be instantiated from this baseobject type in each discipline of geoscience. For example, in geology, someof them are as follows: Composition can be defined as an object type for de-scribing the internal constituents of a sample; Texture refers to descriptionof particle size and particle shape; The object type Genesis is used to de-scribe the historical processes and factors which have led to the formation ofa specific arrangement. Any type of observation and measurement is directlymade on a segment/subsegment or via sample. This base object type canhave association either directly or through a sample with one segment or onesub-segment. A segment or sub-segment may have none or more direct asso-ciation with it. At least one observation or measurement should be relatedto one sample. There could be In Situ Observation and Measurement types,which do not have association with sample, and they are used for describingsegment or sub-segment directly.

26

Classification Reference: In geoscience fieldwork, when a fieldworker ex-amines a sample, a landform, or a geological structure, s/he assigns whats/he observes to a category in a classification reference. This assignment isdone based on her/his knowledge about the used method and theory.

A classification reference through included definition of terms, their com-plete form and abbreviation helps to obtain uniform usage of terms especiallyin big projects, which leads to consistent use of terminology. It also makesavailable the meaning and definition of terms to the fieldworker, so helps ineasier and more precise data entry. In some cases, the findings may not bematched to any of the existing classes, then, if the reasons are satisfactoryand sufficient, a new class with its definition and reasons can be created.

There are different types of classification systems (linear, hierarchical,network). In geoscience, mostly hierarchical classification systems are used(Johnson, et al, 1999). By referring to a specified classification reference ina project or coherent projects, consistency about the detail level of classifi-cation can also be maintained.

3.4 Interpreted Information

Generally, fieldwork in geoscience starts with identifying some part of theEarth, which can be different from other parts. Differentiation can be basedon visual diagnosis, for example, difference in color or shape, but it can alsobe made using remote sensing and satellite imagery. In this stage, a geo-scientist distinguishes the differences and makes some hypothesis based onher/his knowledge. Then, through following a specific method or procedure,s/he tries to find the meaning and a detailed description of the differences,and evaluates the hypothesis scientifically.

The discipline, purpose of study and scale of work determines the proce-dure and working sequence that should be followed. This sequence is shownin the model by defining the spatial object types, their properties and re-lationships. Spatial object types refer to the objects located in space andtime. They are usually characterized by geographic extent. Area of observa-tion, Segment, Site, Route, and Section are the spatial base object types in ourfieldwork metamodel. Spatial object types are geographically linked together.They are represented in the model for describing the spatial positioning inthe field where observations and measurements are made. The other groupof object types are descriptive or non-spatial object types, which are used for

27

representing the characteristics of spatial object types. As the spatial objecttypes are linked together, their related descriptive object types are also linkedtogether, such that observations and measurements made on smaller objecttypes (sample) are used for making interpretations about larger object types(segment).

In fieldwork all the observations and measurements are made on theEarth’s materials, either directly or via samples. The Earth’s material canbe defined as any substance that belongs to the Earth. It can be rock, soil,mineral, organic matter, etc. These materials may be studied for their con-stituent parts, chemical properties, physical properties, their relations witheach other, their structure or configuration within the Earth, their genesisor the history of their formation and other views of interest. In any case,fieldworkers can explain their findings through assigning them to a class ina classification reference, based on the reasons concluded from observations,measurements and their cognition.

Mostly, hierarchical classification systems are used in geoscience disci-plines. Classification reference can have different theme types in a discipline,and specified depth of classification. The classes of theme types are interre-lated with each other.

The mechanism of interpreting in geoscientific fieldwork can be describedas follows: Considering the result of classification and by grouping the relatedfield observations, which are done on specific points, an abstract object canbe defined or inferred, e.g., a boundary. Then, successive boundaries can beused for defining a unit, for example, a rock unit or a soil type unit. Thus,interpretations, classifications, and grouping of field observations related tomore than one spatial object can lead to inference of abstract objects, forexample, a rock unit that may be composed of many outcrop areas. Theseinferred objects can then be used to deduce information about other points.

3.5 A geologic fieldwork data model

Data acquisition in a geologic fieldwork originates from a geographic loca-tion, for example, an outcrop. An outcrop may be sub-divided into morespecific parts. The object type Area of Observation is used for recordinggeneral information about the study area. The object type Site defines alocation about which positioning measurements are recorded. Information ofone positioning measurement can refer to more than one outcrop, but eachoutcrop must have association with one site, where geographical position-

28

ing has been made. The general theme of the study is geology, which canhave more specific branches like, structural geology, engineering geology, etc.Classification reference consists of different groups of classes, e.g., lithology,structure, metamorphology, texture, alteration, etc, which are used for clas-sifying the observations and measurements made in relation to each group.Figure 3.3 shows a typical geologic fieldwork data model, which is derivedfrom the metamodel described in previous sections. Table 3.1 shows the re-lations between this data model’s object types and the base object types ofthe metamodel.

Figure 3.3: A typical geologic fieldwork data model

3.6 A soil survey and its data model

Data collection in soil survey starts by recording observations and measure-ments about a soil profile. Soil profile is an instance type for the base objecttype, Segment. Each soil profile must be occur within one site, one sitemay include more than one soil profile. Route is an object type for defin-ing the path along which sites are located. A soil profile consists of some

29

Data model’ object type —— Base object typeArea of Observation ——– Area of Observation

Project ——– ProjectGeology ——– ThemeOutcrop ——– Segment

Site ——– SiteTraverse ——– RouteSection ——– SectionSample ——– Sample

In Situ Obs./Meas. ——– In Situ Obs./Meas.Classification Reference ——– Classification Reference

Table 3.1: Relations between geologic data model’s object types and Baseobject types of the metamodel

layers. Each layer is called one horizon. So, Horizon is an instance type forsub-segment. The nature of transition from one horizon to the next one isrecorded. In some cases each horizon may be sub-divided into more specificlayers. Observations and measurements are about morphological aspects ofsoil profile like, thickness, color, structure, etc. Different types of samplemay be taken for different purposes from one horizon. Physical properties ofsoil, like porosity, bulk density are recorded via samples specially taken forthis purpose, i.e., undistributed sample, which differs from the sample typetaken for describing and measuring the chemical properties of soil. In thismodel, Soil Taxonomy is an object type used as classification reference forclassifying the result of any kind of observation, measurement, and interpre-tation made in the field. Through grouping and classifying the detailed dataacquired about samples, information about soil profile and in turn about soilunit can be inferred (Burrough, 1991). In Figure 3.4 a typical soil surveydata model, and in Table 3.2, the relations between the object types of soilsurvey model and the base object types of the metamodel are shown.

30

Figure 3.4: A typical soil survey data model

Data model’ object type ——– Base object typeArea of Observation ——– Area of Observation

Project ——– ProjectSoil Science ——– Theme

Route ——– RouteSite ——– Site

Soil profile ——– SegmentHorizon ——– Sub-segmentSample ——– Sample

Sample for phys. properties ——– Sub-sampleSample for chem. properties ——– Sub-Sample

In Situ Obs./Meas. ——– In Situ Obs./Meas.Soil Taxonomy ——– Classification Reference

Table 3.2: Relations between soil survey data model’s object types and Baseobject types of the metamodel

31

Chapter 4

Database schema derivationfrom the metamodel

4.1 Introduction

In the previous chapter, a metamodel for geoscientific fieldwork was de-scribed, as well as two data models that could be instances of the metamodel.The next step in this study is to explain the specifications of a method fordatabase schema derivation. The elements of the metamodel are the meta-concepts, and the relationships among them define the dependency of theelements with each other. For derivation of a database schema from themetamodel, the rules for instantiation of database schema elements from themetamodel’s elements and also the rules about the dependency should beexplained.

In fact, the described metamodel is a common space for any kind ofdatabase schema related to geoscience disciplines, or it can be consideredas a reference model for geoscientific fieldwork databases. The method usedfor database schema derivation from this metamodel should be capable ofpreparing facilities to geoscientists to construct their own specific database,meanwhile keeping them insulated from detail database design operations asmuch as possible.

32

4.2 Specifications of the method for database

schema derivation

The metaconcepts, as the elements of the metamodel, are the most generalconcepts used in fieldwork of different disciplines of geoscience, and it is as-sumed that they cover all the possible elements of the database schema thatcould be defined in geoscientific fieldwork. The method used for databaseschema derivation from our metamodel concern the rules for instantiation ofthe elements of database schema and also the rules for establishing the rela-tionships among them. Instantiation is the relationship between the elementsof a database schema and their related metaconcepts in the metamodel. Inthe diagrams shown in this chapter, the notation used for instantiation is adashed line from the metaconcept to the instance type. For each databaseschema derived from the metamodel, it is not necessary to have a represen-tative of each metaconcept. Thus, metaconcepts can be divided into twogroups:

• Essential (core) metaconcepts: Those metaconcepts that must havean instance type in all derived database schemas. The instance typesof the essential metaconcepts form the minimal set of elements that aderived database schema must have. This group consists of Project,Theme, Segment, Site, In Situ Observation/measurement, ClassificationReference

• Non-essential (optional) metaconcepts: This group may have or maynot have an instance type in a derived database schema. Area of Obser-vation, Route, Section, Sample are the metaconcepts considered as thenon-essential or optional metaconcepts.

The other consideration in the database schema derivation method is themultiplicity of the instance types related to their metaconcept. Some of themetaconcepts can have more than one instance type in the derived databaseschema, and some may have only one instance type. Table 4.1 shows themetaconcepts that can have multiple instance types, and those with onlyone instance type.

33

Multiple Segment, Section, In Situ Observation/instance types Measurement, SampleSingle instance Area of Observation, Project, Site, Theme

type Route, Classification Reference

Table 4.1: Grouping of metaconcepts based on their number of instance types

As a result of the above mentioned characteristics of metaconcepts, in themethod used for database schema derivation the following should be consid-ered:

• Effect of single or multiple instantiation from the metaconcept(s) onthe relationships of the instance types with each other.

• Effect of existence or non-existence of instance type(s) of one or moremetaconcepts on the relationships of the other instance types.

4.3 Instantiation Method

In this section the required steps for instantiating a database schema fromthe metamodel are discussed. The abbreviations used in this section are asfollows:

E = Set of essential metaconceptsNE = Set of non-essential metaconceptsSI = Set of metaconcepts with single instance type

MI = Set of metaconcepts with multiple instance types

Each metaconcept A is a member of the set of essential or non-essentialmetaconcepts and also a member of single instance type or multiple instancetype metaconcept, so:

A ∈ (E ∧ SI) ∨ (E ∧ MI) ∨ (NE ∧ SI) ∨ (NE ∧ MI)

Step 1: Determining the set of instance type for each metaconcept A fordatabase schema D:

34

case 1 : Metaconcept A is a member of E and SI, then the set of instancetype of A for database schema D (instD(A)) will have one member a:

A ∈ (E ∧ SI) then |instD(A)|=1 ⇒ A={ a }

case 2 : Metaconcept A is a member of E and MI, then the set of instancetype of A for database schema D (instD(A)) can have more than one membersa1....an:

A ∈ (E ∧ MI) then |instD(A)|≥1 ⇒ A={ a1....an }

case 3 : Metaconcept A is a member of NE and SI, then the set of instancetype of A for database schema D (instD(A)) can be empty or one:

A ∈ (NE ∧ SI) then |instD(A)|=φ or |instD(A)|=1

case 4 : Metaconcept A is a member of NE and MI, then the set of instancetype of A for database schema D (instD(A)) can be empty, one or more:

A ∈ (NE ∧ MI) then |instD(A)|=φ or |instD(A)|≥ 1

Step 2: Creating a super instance type asup for each metaconcept A forwhich |instD(A)|>1. asup will function as the common supertype of the allmembers of the set of instance type of metaconcept A.

Step 3: Determining the instantiation of relation R between metaconcept Aand B (A R B) for their instance types in database D:

case 1 : The sets of instance type of metaconcepts A and B both have onemember:

|instD(A)|=|instD(B)|=1

This is the simplest case of instantiation. Instance types will have thesame association with each other as their metaconcepts have. In the caseshown in Figure 4.1, an element of instance type a can have association withnone or more elements of b, but an element of instance type b must haveassociation with only one element of a. So the relation r between a and bwill be the same as the relation R between A and B:

35

Figure 4.1: The case of instantiation when both A and B have one instancetype.

(a r b)=(A R B)

case 2 : In this case the set of instance type of metaconcept A has onemember a, and the set of instance type of B has more than one members(b1 ...bn):

|instD(A)|=1 |instD(B)| > 1

As mentioned in step 2, for the members of the set of instance type of B,a supertype bsup should be defined. This case is shown in Figure 4.2. b1 andb2 are the members of the instance type of B and b is a supertype for b1 andb2.

Figure 4.2: The case of instantiation when metaconcept A has one instancetype and B has two instance types

36

case 2-1: In the case shown in Figure 4.2, each member of B must havean association with only one member of A, and each member of A can haveassociation with none or more members of B. This type of relationship is alsotrue for the elements of the instance types of them, so:

(a r b1) = (a r b2) = (A R B)

case 2-2: In this case, each member of A must have association with onemember of B, and each member of B can have none or more association withA.

According to the existing relationship between A and B, an element of amust have association with only one element of b, so this element might befrom b1 or b2. Then, at least one of the associations of a with b1 or b2 mustbe the same as (A R B).

(a r b1)∨

(a r b2) = (A R B)

case 2-3: In this case the single instance type must have association withat least on element of multiple instance type.

Relationship instantiation will be the same as case 2-2.

case 3 : The sets of the instance type of the both metaconcepts A and Bhave more than one members:

|instD(A)|> 1 |instD(B)|> 1

37

Figure 4.3: The case of instantiation when both metaconcepts A and B havemore than one members

As shown in Figure 4.3, according to the rule mentioned in step 3, a isdefined as a supertype for a1 and a2, which are the instances of metaconceptA, and b is a supertype for b1 and b2.

The possible relationships between the members of the sets of instancetypes are as follows:

(a1 r b1), (a1 r b2), (a2 r b1), (a2 r b2),

Figure 4.4: Different types of cardinality constraint for 3 case of relationshipinstantiation

Figure 4.4 shows different types of cardinality constraint between the su-pertypes a and b. Relationship instantiation for each type will be as follows:

38

case 3-1 : This type (Figure 4.4, a), is the same as the case shown inFigure 4.3. Each element of b1 and b2 can have association with one elementof a1 or a2, since if an element of b1 has association with an element of a1and also with an element of b2, then the constraint (1..1) won’t be true aboutit. So:

(a1 r b1)∨

(a2 r b1)=(A R B)(a1 r b2)

∨(a2 r b2)=(A R B)

case 3-2 : In this type (Figure 4.4, b), each element of b must have associ-ation with only one element of a, and each element of a must have associationwith at least one element of b. When an element of a1 or a2 has associationwith one or more elements of b1 or b2, then the association type of a1 withthe other one can be none or more, because the constraint of ‘at least one’,is applied for it with the other type.

case 3-3 : In this type (Figure 4.4, c), elements of a and b can have noneor more association with each other. Then, all the possible relationshipsbetween the instance types of them will be the same as the relation betweenA and B:

(a1 r b1)=(a1 r b2)=(a2 r b1)=(a2 r b1)=(A R B)

case 3-4 : This type is shown in Figure 4.4, (d). The rule for the relation-ship instantiation will be the same as the rule discussed in case 3-2.

case 4: This is the case when one of the sets of the instance type ofmetaconcept A or B is empty (Ø), So:

|instD(A)|= Ø or |instD(B)| = Ø

case 4-1: Metaconcept A is a member of the non-essential metaconcepts,so its set of the instance type for database schema D can be empty. Meta-concept B is a member of the set of the essential metaconcepts and b is itsset of instance type in database schema D:

39

A ∈ NE and B ∈ E|instD(A)|= Ø and |instD(B)| = 1

If metaconcept A has relation with another metaconcept C with non-empty set of instance type in database schema D, then the relation betweenc and b will be the same as the relation between A and B:

(c r b) = (A R B)

Case 4-2: If metaconcept A has no relationship with any other metcon-cept than C, then the relation R won’t have instance type in database schemaD:

In the next section, the different aspects of instantiation will be discussed foreach metaconcept separately.

4.4 Instantiation of database schema elements

Project: Project type has two associations, one with Theme type and theother one with Area of Observation type. Project and Theme both, are es-sential and single instance type metaconcepts, so the instantiation of theirrelationship will be as the case 1 of step 3 of instantiation method. Its otherassociation is with Area of Observation, which is a member of SI and NE.

40

If an instance type for Area of Observation is defined in database schema,their relationship will be as the case 1 of step 3. If an instance type for Areaof Observation is not defined, then the instance type of Project will haveassociation with instance type of Segment (case 4-1). Since Segment is inMI, if it has more than one instance type, the rule of step 2 of instantiationmethod should be applied.

Figure 4.5: Instantiation of Project and Area of Observation relationship

As shown in Figure 4.4 different cases of instantiation of relationship be-tween Project and Area of Observation are:(a)- When both have single instance type in derived database schema.(b)- No instance type for Area of Observation, and single instance type forSegment.(c)- No instance type for Area of Observation, and multiple instance typesfor Segment. S1 and S2 are the instance types of Segment, S is supertype forS1 and S2.

Area of observation: Area of Observation, other than Project has asso-ciations with Segment, Site, and Route. If an instance type for Area ofObservation is not defined, its relationships with object types other thanProject, will not have instance type in derived database schema, because allof these three object types are associated to each other (case 4-2).

Route: Route is member of SI and NE. If an instance type for Route is notdefined, then its relationships with Area of Observation and Site will nothave instance type in derived database schema. If Route has instance type,

41

instantiation of its relationships with Area of Observation and Site will beas the case 3-1.

Site: This base object type is a member of E and SI. Instantiation of itsrelationships with Area of Observation and Route were discussed. About itsrelationship with Segment, since segment can have multiple instance types,their relationship in derived database schema will be either as case 1 or ascase 2-3 of step 3 of instantiation method. Because each segment can occurin one site, So an element of one segment type can not have association atthe same time with two sites.

Segment - In Situ Observation/Measurement: These two metacon-cepts are the members of E and MI. So, instantiation of their relationshipwill be as one of the sub-cases (3-1, 3-2, 3-3, 3-4) of case 3 in step 3 of in-stantiation method. An instance type of In Situ Observation/Measurementshould have association with one Segment either directly or through Sampleand Section. Therefore, in some cases Segment type may have none or morerelationship with instance type of In Situ Observation/Measurement. In casewithout defined instance type for Section and Sample, Segment type musthave association with at least one In Situ Observation/Measurement.

Sample - In Situ Observtion/Measurement: Sample type is memberof NE and MI. If instance type(s) for sample is/are defined, for each samplethere must be an observation or measurement type. But there could be ob-servation and measurement types that have no association with sample, thenthey must have association directly with segment or sub-segment.

Section - Sample: Existence of instance type of section type depends on theexistence of instance type for Sample. Without sampling a section can not bedefined. But sample type can have instance independently from the existenceof Section type instance. When an instance type for Section is not defined,then each sample must have association with at least one segment or sub-segment, and for each sample at least one In Situ Observation/Measurementtype should be defined.

42

Chapter 5

Conclusions andRecommendations

5.1 Conclusions

In this study, we tried to design a generic fieldwork metamodel, which canalso be called a reference model, such that different kinds of geoscientificfieldwork database schema can be derived from it. For achieving this aim, itwas necessary to understand fieldwork conceptually, to understand the na-ture of field data in geoscience , their differences with data in other domains,and to find the most general concepts used in geoscientific fieldwork.

• The Earth’s systems are open and complex, multiple models can bemade to explain a geographical phenomena.

• Acquired field data are not just observations, but also interpretations.Environmental condition, applied method for data acquisition, and cog-nition level of observer are the factors influence the interpretations andinferences made in the field.

• Database schemas with fixed and static structure are problematic forusing in geoscientific fieldwork. Designing a generic model providesfacility for geoscientists to construct project-specific database schemasfor storing and managing acquired data correctly.

43

• Concepts at higher level of abstraction are relatively fixed, so mod-els founded on such concepts will be more stable and also they willbe more independent on situational conditions, new explorations, andrevised theories. We tried to find the most general concepts used ingeosientific fieldwork for constructing the metmodel. Thus, the meta-model will have more stable structure and can be used as a referencefor designing database schemas with flexible and dynamic structure.

• Classification mechanism provides a way for establishing relations be-tween observed data and interpreted or inferred information. So wetried to consider this mechanism in design of metamodel through defin-ing the metaconcepts Theme and Classification Reference.

• The most general concepts (metaconcepts), which were used as thecomponents of the metamodel are as follows: Area of Observation,Project, Theme, Site, Segment, Route, Section, In Situ Observation/ Mea-surement, Sample, Classification Reference. It is assumed that thesemetaconcepts cover all possible object types of geoscientific fieldworkdata models.

• Essential metaconcepts (Project, Theme, Segment, Site, In Situ Obser-vation/Measurement) form the minimal set of the object types of anyderived database schema. Existence of instance types of non-essentialmetaconcepts (Area of observation, Route, Section, Sample) in deriveddatabase schema is optional.

• Some of the metaconcepts can have multiple instance types (Segment,Section, In Situ Observation/Measurement, Sample) and some can havesingle instance type (Area of Observation, Project, Site, Theme, Route,Classification Reference).

• For instantiating database schema from the metamodel, we tried todescribe the specifications of the instantiation method, and the stepsthat should be followed. The rules for instantiating the object typesand the rules for relationship instantiation were defined.

44

5.2 Recommendations

This study can be the first step for developing a system for organizing andmanaging geoscientific fieldwork information. Generality of the metaconceptsand consistency of the model can be checked during implementation stage.So, the next step as complementary work of this study is to develop a proto-type system for real data entry, which may lead to redesign and improvementof the model. A user interface should be designed, such that users can createor instantiate their own specific database schemas through answering designquestions and choosing appropriate options. The system should be able toguide the users to follow the instantiation method steps, and also the systemshould be able to establish the correct types of relationship and constraintbetween the instance object types. In this way, geoscientist would be able tocreate their own specific databases individually, and also be kept insulatedfrom detailed database design operations.

45

Bibliography

[1] Barnes, J.W., 1995, Basic geological mapping, John wiley and sons Ltd.

[2] Bate, R.L., Jackson, J.A., 1987, Glossary of geology, third Edition:Americal Geological Institute, Alexandria, Virginia

[3] Blaha, M., Premerlani, W., 1998, Object-Oriented Modelling and De-sign for Database applications, Prentice Hall

[4] Brodaric, B. 1997, Field data capture and manipulation using GSCFieldlog 3.0, In Soller, D.R., ed., Proceedings of a workshop on digi-tal mapping techniques: Methods for geologic map data capture, man-agement, and publication: U.S. Geological Survey Open-File Report97-269, p. 77-82.

[5] Brodaric, B. , 2001, The Design of Fieldlog: Ontology-based Softwarefor Computer Aided Geological Field Mapping

[6] Brodaric, B. 2000, Digital Geological Knowledge: From Field to Mapto the Internet, In Soller, D.R., ed., Digital Mapping Techniques ’00-Workshop Proceedings U.S. Geological Survey Open-File Report 00-325.

[7] Brodaric, B., Harrap, R., Lemkow, D., 2001, FieldLog V. 3.0: User’sGuide and Reference, Geological Survey of Canada, Open File 3239

[8] Brodaric, B., Gahegan, M. 2002, Distinguishing Instances and Evi-dences of Geographical Concepts for Geospatial Database Design, InGeographic Information Science 2nd Int’l conference, GIScienec 2002,M. Egenhofer and D. Mark (eds.), LNCS 2478, Springer, Berlin.

[9] Brodaric, B., Hastings, J. 2002, An object model for geologic map infor-mation. IN: Advances in Spatial Data Handling, Springer-Verlag, NewYork.

46

[10] Broome, B. Brodaric, B., Viljoen, D., Brail, D., 1993, The NATMAPDigital Geoscience Data-Management System, In Computer and Geo-science, vol. 19, No.7 pp. 1501-1516

[11] Burraough P.A., 1991, Soil Information Systems. In: Maguire D.J.,Goodchild, M.F., Rhind, D.W.(eds.), Geographical Information Sys-tems: Principles and Applicayions, Longman, London, pp. 153-69, vol.2.

[12] Chew, K.J., 1995. Data modelling a general purpose petroleum geolog-ical database. In: Giles, J.R.A. (ED.) Geological Data Management,Geological Society, London, special publication, no. 97. pp. 13-23.

[13] Giles, J.R.A., Bain, K.A., 1995. The nature of data on a geologic map.In: Giles, J.R.A. (ED.) Geological Data Management, Geological Soci-ety, London, special publication, no. 97. pp. 33-40

[14] Gregorich, E.G., Turchenk, L.W., Carter, M.R., Angers, D.A., 2001,Soil and Environmental Science Dictionary, Canadian Society of SoilScience

[15] Johnson, B.R., Brodaric, B., Raines, G.L., Hastings,J.T.,Wahl,R., 1999, Digital Geological Map Datamodel, version 4.3http://geology.usgs.gov/dm

[16] Oxford Advanced Learner’s Dictionary (1993)

[17] Rasmussen, K., 1995. An overview of database analysis and design forgeological systems. In: Giles, J.R.A. (ED.) Geological Data Manage-ment, Geological Society, London, special publication, no. 97. pp. 5-11.

[18] Richard, S.M., 1999, Geologic Concept Modelling, with Exam-ples for Lithology and Some Other Basic Geoscience Features, InD.R. Soller, ed., Digital Mapping Techniques ’99-Workshop Pro-ceedings U.S. Geological Survey Open-File Report 99-386, p. 59-76,http://pubs.usgs.gov/openfile.of99-386/richard.html

[19] Rumbough, j., Jacobson,I., Booch,G., 1999, the Unified Modelling Lan-guage Reference Manual. Addison-Wesley.

[20] Schetselaar, E., 1995, Computerized Field-Data Capture and GIS Anal-ysis for Generation of Cross Sections in 3-D Perspective views: Com-puters and Geosciences, vol. 21, no. 5, pp. 687-701

47

[21] Sowa, J.F., 1984, Conceptual Structures, Information Processing inmind and machine, Addison, Wesley

[22] Woldai, T., Schetselaar, E.,2002, Design and Implementation of“Factual” databases to support GIS/RS analysis of the Earth systemsfor civil society, the International archives of the Photogrammetry,Remote Sensing and Spatial Information Sciences, Vol. 34, part XXX.

48