ON-SITE DIGITAL HERITAGE INVENTORY DEVELOPMENT AT BAT , OMAN

This paper reports on the on-site development of a local-scale digital heritage inventory (DHI) of the Bronze Age site at Bat in the interior of Oman. The goal of this inventory project was to share geospatial and archaeological information of tombs and other built structures with researchers and government agents to conduct cultural heritage management, scientific research, outreach, and education. To this end, the Bat Digital Heritage Inventory (BatDHI) was compiled at the local office by incorporating previous survey records, which were concurrently crosschecked and updated by ground-truth surveys. The current version of the BatDHI was implemented using a combination of a network-access-ready database application, open source geographical information system, and web-based map engine. This system assisted both fieldwork and management works including decision making and planning. This inventory project exemplified a transdisciplinary research, in which researchers and societal stakeholders collaborated for co-design of research agendas, co-production of knowledge, and co-dissemination of outcomes.


INTRODUCTION
Bat (pronounced "baat") is a protohistoric settlement site, located at the geographic front between the Rub al-Khali Desert and Hajar Mountains in the interior of Oman.In terms of archaeology, Bat is known as one of the best-preserved oasis towns of the Bronze Age (ca.3200-1300 BC) in Southeast Arabia.The site was discovered in 1966, and since the middle of the 1970s, the Danish and British expeditions have surveyed and excavated settlements and tombs dated to the Hafit (ca.3200-2750 BC), Umm an-Nar (ca. 2750(ca. -2000 BC) BC), and Wadi Suq periods (ca. 2000(ca. -1300 BC) BC), as well as circular built structures ("towers") of the Umm an-Nar period (De Cardi et al., 1976, Frifelt, 1976, Frifelt, 1985, Brunswig, 1989, Gentelle and Frifelt, 1989, Frifelt, 2002).In 1988, Bat was inscribed to the UNESCO World Heritage List with the neighboring sites of Al-Khutm and Al-Ayn, based on the criteria of (iii) uniqueness and (v) environmental vulnerability (UNESCO, 1988).The UNESCO-designated protection areas, covering the main portions of the site, were reported in 2000 (Cotto, 2000).Succeeding these missions, German and American teams have been working at the site until now (Böhme andAl-Sabri, 2011, Thornton et al., 2013).
On request of the Omani Ministry of Heritage and Culture (MHC), the authors' team started developing an inventory of archaeological features inside the UNESCO area of Bat in 2013.The goal of this inventory project was to share geospatial and archaeological information of tombs and other built structures with researchers and MHC officials to conduct cultural resource management (CRM), scientific research, outreach, and education.For this purpose, the inventory was to be shared with (1) the research team seasonally coming to the site from Japan, (2) MHC staff members working at the local office, (3) MHC officials at the headquarters in Muscat, and (4) other researchers and local stakeholders.Since these actors normally work in remote places, a network-based data sharing system was necessary for this enterprise.* Corresponding author.
In order to build such a data sharing system for the heritage management at Bat, we applied a digital heritage inventory (DHI) or geospatial database system specialized in CRM.DHI systems are already applied to national level CRM projects in the Middle East and the Gulf regions, exemplified by the MEGA-Jordan (Myers and Dalgity, 2012) and the Qatar National Historic Environment Record (Breadmore et al., 2010).Open source DHI applications, such as Arches (http://archesproject.org)developed by a joint project of the Getty Conservation Institute and World Monuments Fund (Myers et al., 2012, Myers et al., 2014), have boosted their availability for and applicability to CRM projects at different places and regions in different spatial scales, with following the international standard CIDOC-CRM (ISO, 2006): They are also applicable to local-scale CRM projects.Based on this thought, the authors have been developing the Bat Digital Heritage Inventory (BatDHI) to manage and share archaeological information on site.This paper presents concepts, data flow, metadata structure, preliminary results, and assessments of the BatDHI project.

CONCEPTS
Key concepts of the BatDHI are summarized by three wordssimplicity, sustainability, and security:

Simplicity
The BatDHI system was designed to be as simple as possible to guarantee easy access and wide use.Internet-based applications were selected for the system so that people in remote places can share information.It should be used as easily as Facebook and Google Maps, regardless of user's different levels of computing skills.
Regarding the accessibility, it is noted that wireless Internet access has dramatically been improved in the Bat region in last few years, and a broadband Internet connection was established in the local office.Smartphones and tablet PCs, with which we can browse maps in the field with wireless Internet connection, have more easily been available.These advantages in the telecommunication infrastructure made it possible to establish a networkbased data sharing system at Bat so that researchers and local staff members can access and share information through the Internet on site.

Sustainability
From the technical viewpoint, the system must be sustainable because it should be maintained for a long time despite a user's lack of deep knowledge and experience of computing, software engineering, and network systems.Both technological and economic requirements for the sustainable development of the DHI must be as low as possible.For these reasons, a combination of easy-touse and low-cost applications were selected (see Section 3.).The system should be applicable in other projects in different sites and regions.

Security
The BatDHI should be open to public inspection in the future.However, it may contain secured information, such as buffer zones under planning and land ownerships.Therefore, the information was controlled by three different tiers of authorized access (Figure 1).At the first tier, BatDHI team members used the system to compile, share, and edit data.At the second tier, MHC staff members were invited to share the contents.They were allowed to access secured information.Security was kept by limiting users informed of the access address (or URL).At the third tier, limited and simplified contents will be open to public inspection through the Internet in the future.

DATA FLOW
The BatDHI contains information on the archaeological features and bibliography of Bat, Al-Khutm, and Al-Ayn.At the first step of data preparation, survey records of previous missions (Frifelt, 1985, Cable, 2012) were collected in digital formats.For the current survey project, worksheets were electronically scanned and converted to the PDF format (see Section 4.).Photographs were digitally kept in the JPEG format.Digital data captured with mobile devices such as the Global Navigation Satellite System (GNSS) receiver and field GIS (ArcPad) were downloaded and converted into a Microsoft Excel file.Files were securely saved in Dropbox (https://dropbox.com),an online data storage and sharing service.
The current version of the BatDHI was implemented using a combination of a network-access-ready database application, open source geographical information system, and web-based map engine.A relational database management system (RDBMS) was developed to contain the survey records and photographs in an integrated manner (see Section 4.).The system was implemented using FileMaker Pro, a small-scale relational database application.The database could concurrently be edited through a local area network.
Interactive and multi-scalar maps of archaeological features are the most essential information sources to form a consensus and make a decision.Therefore, GIS was employed to manage, integrate, and visualize geospatial data such as shapefiles of archaeological features, GNSS track logs, Digital Elevation Models (DEMs), digitized maps, and airborne and satellite images to create maps as final products.
Coordinates (or easting and northing values) of features were used for GIS data.Shapefiles of point features, as well as polyline features (such as stone alignments) and polygon features (such as boundary of mounds and artifact scatters) were managed with an open source GIS (QGIS 2.6) while considering the possibility that an increasing number of staff members would take part in editing data in near future.A web-based interactive map service was prepared by means of the Google Maps Engine based on spreadsheets from the main database and KML files of features exported from QGIS (Figure 2).This web-based map dramatically improved the workflow on site: Surveyors browsed the map with the Google Maps App on their smartphones during fieldwork in order to locate themselves and to find features to be documented.The map was updated on a semi-real time basis: When an information engineer uploaded new files exported from the main database to the Google Maps Engine, the update was immediately reflected to the smartphone app.This system was very useful for not only fieldwork but also sharing information between MHC officials working at Bat and those in Muscat.

METADATA STRUCTURE
Figure 3 shows the entity-relationship diagram of the BatDHI RDBMS.The database comprised three tables on archaeological elements (ElementDHI, ElementCable, and ElementGerman-Plus), a table of bibliographic information (Reference), pictures (Images), and registered artifacts (ArtifactRegistered).In this database, elements refer to individual archaeological feature such as a cairn, tomb, tower, building, or stone alignment.The main table was ElementDHI, in which results of the archaeological survey in this season were recorded.One or more images, including photographs, stitched orthoimages of overhead photography, and map screenshots, were linked to the relevant record in a many-to-one cardinal relationship.ElementCable and Element-GermanPlus contained records of the previous surveys (Cable, 2012, Böhme andAl-Sabri, 2011).Data fields are described in the following subsections.

Elements
Data fields and specifications of the ElementDHI table are as follows (Figures 4 to 8  (Frifelt, 1976, Frifelt, 1985) and German one (Böhme and Al-Sabri, 2011).Text.• CMC ID: Serial identifier for individual elements, assigned by Cable's survey (Cable, 2012).It is composed of six digits beginning with the last two digits of the year.This identifier is used as the primary key to related tables.• GNSS type ("GNSS type" on the GNSS tab): Type of GNSS device used for measuring coordinates.The vocabulary is strictly controlled.One value is selected from Garmin GPS, Hemisphere DGPS (differential GPS), and Trimble GNSS.4.1.5Architecture (Figure 7) • FeatBotLength, FeatBotWidth, FeatHeight (relevant to "Bottom length (or diameter)", "width", and "height" on the Architecture tab): Length, width, and height of the element in meters.These values were copied from those measured by previous surveys if any.Double.8) • Remarks (The window on the top of the Comments tab): Descriptions of the monument.The comments of previous surveys (Cable, 2012) were copied from the original data files and added to this field.

References
References were described in a standard format, compatible to the BibTeX (http://www.bibtex.org).

Images
The data fields and specifications of the Image table are as follows: • UID, DHI number: See Section 4.1.
• ImageIRI: IRI of the relevant image saved in Dropbox (if any).• Image: Image file embedded.The data type is object.
• ImageFileName • PhotoDirection: Direction of Photography.One value is selected from N, NE, E, SE, E, SW, W, or NW.Other values (NNW for example) are also allowed.

GROUND TRUTH SURVEY
Previous survey records (Frifelt, 1985, Böhme and Al-Sabri, 2011, Cable, 2012) were crosschecked through fieldwork.Geocoordinates of each feature (or element) were measured with a GNSS receiver with sub-meter accuracy.Mounds and stone alignments were mapped by means of a field GIS (ESRI ArcPad).The survey was assisted by an interactive DHI map powered by the Google Maps Engine (Figures 9 and 10).Thanks to this map on a smartphone, surveyors easily managed to identify features to be checked on site.Reports of individual elements exported from the File-Maker database (Figure 11) were also helpful in the survey and post-survey data processing.
As a result, 634 elements were reconfirmed present in and around the UNESCO World Heritage areas (red boundary in Figure 9).Those included 289 Hafit-type cairns, 59 Umm an-Nar tombs, 7 third millennium towers, 30 Wadi Suq tombs, 80 Iron Age tombs, and 76 traces of stone alignments, which were typically made of bifacial stone foundation.
As pointed out by the previous studies (Böhme, 2011, Cable, 2012), Hafit-type cairn tombs were mainly aligned on the ridge.However, cairn tombs in the UNESCO World Heritage area were characterized by a well-preserved cluster (DH 112 to 132, 147 to 155 in Figure 9 for example) on the terrace at the foot of the hills.Those were probably built in the transitional phase leading up to the subsequent Umm an-Nar period.A cluster of Umm an-Nar-type circular tombs was built on the terrace to the southwest of the transitional cluster (Böhme, 2011).The third millennium towers were located in the floodplain.The subsequent Wadi Suqtype oval tombs were also located on the terrace (DH 266 to 273).A cluster of subterranean graves of the Iron Age was also discovered on the opposite bank of the main cemetery.More than 40 subterranean graves (DH 190 to 239) were clustered in a diameter of 100 meters there.
There were also a number of rectilinear stone alignments in the floodplain.They evidenced the presence of residential structures and water management systems such as dams and bunds.Most of the tombs were built to the north of the semicircular long wall (Frifelt, 1985).It seems that the main settlement might have been located in the central floodplain in the western periphery of the World Heritage area.Another complex of Umm an-Nar tombs and platforms was identified on the hill to the east of the so-called Settlement Slope (Frifelt, 1985, Brunswig, 1989).A possible settlement area, evidenced by bifacial stone wall foundations, was also identified on the terrace to the south of the Settlement Slope.

ASSESSMENTS AND CONCLUSIONS
The authors developed the first version of the DHI for the UN-ESCO World Heritage sites of Bat, Al-Khutm, and Al-Ayn.The inventory (BatDHI) integrated the information of the previous surveys by Danish, German, and American expeditions in order to draw a complete figure of the geography of monuments in the World Heritage areas and buffer zones.The records were validated by the ground-truth survey.The coordinates of monuments were updated with a high-resolution GNSS device.The system was simple enough and therefore suitable for the on-site CRM, with which non-researchers at different levels of PC skills were involved.
It is also noted that this inventory project provided a new research development in heritage management with a transdisciplinary approach, in which researchers, governmental agents (MHC officials and local staff members in this case), and other societal stakeholders collaborated for co-design of research agendas, coproduction of knowledge, and co-dissemination of outcomes (Leavy, 2012, Mauser et al., 2013).
In near future, other geospatial data will be integrated and managed in the BatDHI.Among them, vector data may include (1) point clouds of benchmarks, topography, and centroids of built features, (2) polyline features of roads and drainages, (3) polygon features of cadastral areas and site coverage.On the other hand, raster data may include satellite images such as LAND-SAT, ASTER, ALOS, and GeoEye-1 for base maps, orthoimages derived from airborne or overhead photography, Digital Elevation Models (DEMs), and results of spatial analyses and modeling.A combination of these spatial data and information on archaeological elements will facilitate further research and CRM in a more effective manner.
The authors are also planning to install the upcoming release (version 3.0) of Arches open source DHI for the next version of Bat-DHI, which will become a pilot system for larger-scale heritage inventories in the region.

Figure 1 :
Figure 1: Data access tiers of the BatDHI.

Figure 2 :
Figure 2: Data flow in the BatDHI project.

•
SiteName (Site): The site name is contained in the "Site-Name" field (Figure3) and shown in the "Site" window on the interface (Figure4).The vocabulary of attribute value is strictly controlled: One value is selected from the list (Bat, Al-Khutm, or Al-Ayn).This would not allow any exceptions by default.The data type is always text.• UID (Worksheet UID): A unique identifier for distinguishing individual records (or worksheets).UID is put to every data element regardless of the type of data entity (i.e., worksheets, GPS log files, images, references, etc.).It is composed of ten digits, representing the last two digits of the year, followed by two digits of month, day, hour, and time of the data entry.For example, UID 1401091023 means that the entry was created at 10:23 am, January 9, 2014.The data type is long integer.• DHI Number (DHI No.): Serial identifier for individual elements, assigned by the project team.Short integer.• DanishID, GermanID: Serial identifier for individual elements, assigned by Danish expedition

•
UTM Easting/Northing (UTM Easting/Northing): Geocoordinates based on the Universal Transverse Mercator spatial projection system zone 40N.The data type is doubleprecision floating point (hereafter called "double").The values were calculated from the WGS84-based coordinates by using the geometry calculation of ArcGIS.• Latitude, Longitude: WGS84-based latitude and longitude in decimal (dd.dddd).Double.• FeatType (Element Type): Category of element.The vocabulary is loosely controlled.One value is selected from cairn, tomb, tower, mound, or stone alignment.Other values are also allowed if necessary.Text.• GroundTruth (Ground truth validated by the Japanese team?):Yes/no flag to indicate whether or not the relevant monument was checked in the field.The data type is binary.• WorksheetIRI (Worksheet IRI): International Resource Identifier (also called Uniform Resource Identifier, or URI) of the original worksheet PDF uploaded to the Dropbox cloud storage.This helps users to browse the worksheet.The data type is text.4.1.2Location (Figure 4) • DGPS OmanTMfrom/to (GNSS time): Local time of the beginning and end of a DGPS session.Five or six digits in the format of hhmmss (102141 means 10:21:41 for instance).Long integer.

Figure 5 :
Figure 5: Interface of the ElementDHI table (Topo tab).• DGPS TotalPts (points): Total number of GPS points taken in the track mode.Short integer.• DGPS PDOP filter (PDOP filter): Filtering value (or threshold) of PDOP (position dilution of precision) score, which indicate an index of data quality.Double.• DGPS PDOP avg (PDOP average): The average of PDOP values after omitting bad quality (or high value in PDOP) points.Double.• DGPS filteredPts (points): Total number of points reserved for the average calculation.Short integer.• GISDataType (Primary GIS data type): Type of GIS shapefile (point, polyline, or polygon) for the monument.The vocabulary is strictly controlled.Text.• FeatID (Feature ID): Temporal identifier of features in the shapefile.Long integer.

Figure 8 :
Figure 8: Interface of the ElementDHI table (Comments tab).strictly controlled.One or more values are selected from the list (Paleolithic, Holocene Pre-Hafit, Hafit, Umm an-Nar, Wadi Suq, Iron Age, and Islamic).Text.• Artifacts: Type of artifacts collected.One or more values are selected from the list (ceramics, lithics, worked stones, stone vessels, beads, and metal objects).Other values are also allowed if necessary.Text.

Figure 9 :
Figure 9: A Google Maps Engine interactive map of the BatDHI, showing the spatial distribution of archaeological features in and around the UNESCO area (red).

Figure 10 :
Figure 10: An example of the retrieval of a feature by attributes on Google Maps Engine.

Figure 11 :
Figure 11: An example of the report of a feature exported from the BatDHI FileMaker database.