About ASPIRE

Implementation Quick Summary

Implementing ASPIRE is actually very easy. This document is large and complicated because it contains all the reference material that might be needed to start from scratch. Because you can download template databases, data dictionaries, GIS coverages and GIS legends from the ASPIRE website (or have them supplied by the relevant LA Archaeologist) you will be able to get started immediately. For example, if you are carrying out a survey you would first request SMR data for the area in question, if this data complies with the specification all the necessary fields are in place for you to fill in new sites or additional site information. To specify the area in which your survey has taken place you can download a template Events GIS layer, which has all the necessary fields specified in its attribute table, polygonise your survey area, fill in the attributes and that’s it.

All that requires to be submitted to the SMR(in the first instance) and the NMRS to comply with ASPIRE are:

ASPIRE Database
- Event Record
- Site Record(s)
- Metadata (which includes info on reports or other data generated by this project)
- Completed Checklist table
ASPIRE GIS coverage (if GIS was used in your event)

The database contains forms, reports, a checklist and detailed instructions to make this as easy as possible. The database also contains a Data Dictionary, in which the form and acceptable values for each field is detailed. In the first instance this table will be vital in understanding how to submit data that complies with ASPIRE. In the template database this Data Dictionary can be accessed directly through its own form or through the blue question mark symbols next to each field.

1 Introduction and Background

The volume of data generated by archaeological fieldwork in Scotland has never been greater, much of this is due to the work generated in response to new development, in fact the vast majority of archaeological fieldwork is now instigated in response to planning legislation (called development control or ‘DC’ work in this document), but rescue, research and survey archaeology are also responsible for considerable amounts of new information being generated every year. The number of organisations generating this data has also never been so large, there are around twenty commercial archaeological contracting units, the RCAHMS survey, fifteen SMR services, a number of universities with active projects as well as numerous national and local amateur organisations and private individuals. This means there are tens of bodies working on hundreds of projects, each structuring their data and reporting their findings in differing ways, often from project to project.

All new archaeological work requires to be informed by previous work in its geographical location or at similar sites in order for it to be meaningful (this includes the case where there has been no previous work in an area or a particular type of site). The record of previous archaeological work (including records of sites) that might be required to inform a new project is often referred to as ‘base-line information’ Such information acts as a form of meta-data, it contains locational and summary information and directs the enquirer to the original data sources. There are number of sources of base-line information in Scotland such as the National Monuments Record of Scotland (NMRS, curated by the RCAHMS), Historic Scotland (HS, for scheduled ancient monuments and listed buildings) the National Library of Scotland (NLS) etc. The NMRS is a national collection comprising data in various formats: archived manuscripts, published documents and ‘grey literature’, as well being the national depository for archaeological fieldwork archives. Summary information on archaeological sites and events is held in an Oracle database and made available on-line via CANMORE and Pastmap . Given the volume and varied nature of new archaeological information the time cycle in which newly generated information finds its way into the summary index of the NMRS may be significant. For ‘land management purposes’ e.g. DC work, the primary sources of base-line archaeological information are the local SMRs, although this does not mean other sources should not be consulted. These sources are responsible for ensuring that up to date NMRS summary data are incorporated into their own record, in addition more current and field-verified data is held in each local SMR. As SMRs are hosted within the archaeological services responsible for providing archaeological advice to planning authorities their information and advice relating to recent archaeological events and the planning context of DC work is the core resource for archaeological work of this type.

Given the ever increasing amounts of archaeological data, ever increasing types of data, ever increasing numbers of people generating it and ever increasing demands for access to it, a more coherent approach to how this data is structured, deposited and delivered across all sectors is archaeologies most pressing priority. A series of meetings in 2003/2004 between the SMR Forum and Scottish archaeological contractors and National bodies on these issues culminated in a meeting in November 2004 in which a consensus was reached that a standard specification for archaeological data generated by fieldwork and research projects and a protocol for its reporting would be highly desirable in terms of data flow between SMRs, the RCAHMS, archaeological contractors and the public. The proposed protocol was designated the ‘Archaeological Standard Protocol for the Integrated Reporting of Events, to be known by the acronym ASPIRE.

The protocol has been developed by the ASPIRE Project Team (APT), this consists of the SMR Forum Technical Working Group and the Geo-spatial Standards Working Group. These two groups have representatives from Historic Scotland, the RCAHMS, archaeological contracting units and ARIA. The APT is responsible for coordinating the responses and comments from all interested parties on the protocol.

This document represents the first version of the data specification, and the protocol for the creation and deposition data conforming to it. It is intended to give clear guidance on how new archaeological information is expected to be structured as well as minimum standards on how it is to be formatted, presented, deposited and delivered.

ASPIRE is specifically designed for reporting that an event has taken place and providing summary information of that event and for reporting new site information in summary – it is not intended as a substitute for full archaeological reporting of excavations or of surveys. ASPIRE should not in any way minimise the amount and type of information that can be ultimately reported nor should it in any way stifle the adoption of new approaches in site recording or data structure. ASPIRE represents a minimum level of event/site reporting and specifies how data should be formatted and presented for curatorial purposes, it does not represent a template for fieldwork recording per se, nor is it a set of guidelines on how to write a full publication standard archaeological report. It is also important to note that the adoption of this specification does not, in most cases, represent a request for more information or more work on the part of the originator, what it does ask for is changes in how that information is structured and presented so that local and national curators and other recipients of the information can derive maximum benefit from it. The use of ASPIRE will also benefit data users, as it is also intended to facilitate the provision of all SMR datasets nationally via a web portal, this will lead on from the enhancement of the HS/RCAHMS Pastmap project to incorporate SMR information amongst its datasets.

1.1 Timetable

It is hoped that SMR inclusion in Pastmap will be formally launched in October 2005 and further developments such as Eventmap will follow thereafter. The first stage of this, a pilot project involving Perth and Kinross and Aberdeenshire SMRs was implemented in spring 2005. With this in mind, the pace at which this protocol is adopted should be fairly rapid as the supply of SMR data via a portal will to some extent be contingent on the supply of data to SMRs in a useable and coherent format (i.e. ASPIRE). The protocol was formally adopted (in principle) by the SMR Forum in March 2005 and will be promoted as best practice as soon as comments on this version (1.3) have been collated and integrated. This will precede the hoped for implementation of the Scottish version of OASIS, expected sometime in 2006, however because the ASPIRE Event Reporting standards have been designed to compliment those of OASIS the transition to OASIS should be smooth, instead of reporting events by supplying data as described in Section 3.1.1 it will be supplied online via the OASIS system (Section 3.1.2). The proposed date at which use of this protocol will be enforced via the planning system or as a condition of contract is April 2006. It should be noted that the timetable for OASIS has not been finalised, and although ASPIRE is designed to integrate with OASIS, it is not entirely contingent on it so the ASPIRE timetable will go ahead independently of OASIS’s.

The objective of this timetable is to allow archaeological contractors time to integrate the adoption of the ASPIRE protocol into there working practices as well as allowing time for unforeseen problems to be appropriately addressed prior to its use being enforced (see Section 2). This time period is projected to be four months (November 2005 – April 2006).

Training and assistance in implementing ASPIRE for archaeological contractors is intended to be made available prior to April 2006, the exact form and source of this training is yet to be agreed, but is actively being pursued by the APT and the SMR Forum and is likely to be a joint endeavour between the RCHAMS, SMRs and the ADS.

1.2 SMR Variability

The current situation with locally held SMR datasets is highly variable both in terms of software, hardware and data structure. This variability might suggest that receiving new archaeological data or event reports in a standardised format might not be particularly beneficial for some SMRs. This could be thought to be especially true given the emphasis that ASPIRE has on digital data, which some SMRs are not well equipped to handle as yet. In recognition of the fact that archaeological contractors will find it easier to work to the general specification if they know it will be required from all contractors everywhere in Scotland, all SMRs will insist on its use in their Standard Conditions for archaeological contractors. This begs the question: what will happen to the submitted digital data if it cannot be immediately used by the SMR? The RCAHMS has agreed to act as temporary host to this data for those SMRs that are not in a position to fully utilise it immediately, in effect ASPIRE compliant archaeological data should be deposited with the SMR who will then be able to check its compliance and integrate it immediately into its own datasets (where possible) and deposit it for long term preservation with the RCAHMS.

1.3 Who should use ASPIRE and why.

Below are the most common contexts for archaeological fieldwork carried out in Scotland along with explanations of how and why ASPIRE should be used in them. The following section explains in more detail the ways in which the general specification will be made as easy as possible to implement through the provision of exemplar and template digital files and documents.

1.3.1 Archaeological contractors engaged in planning related work

If you are an archaeological contractor working for a developer who has commissioned work in support of a planning application, or to discharge a condition on an existing consent the use of ASPIRE will be required by the relevant planning authority. Each planning authority (with one exception) has an archaeological advisor who will recommend what archaeological work may be required and who will monitor that work in the field and comment on the standard of reporting of that work. All Scottish LA Archaeologists have agreed that ASPIRE compliance will be enforced by them, even where they are not in a position to directly benefit. Specifically, this means that a condition on a planning consent cannot be discharged if the archaeological reporting required is not ASPIRE compliant.

From the above it should be clear that all contractors in all areas of Scotland will be working to the same specification and no contractor can gain a commercial advantage by reporting to a lesser specification. All tenders/costings should reflect the need to adhere to the general specification and explicitly state the intention to do so (see Section 2 for more details on how to do this)

1.3.2 Archaeological contractors or researchers contracted by HS

Historic Scotland have recognised the desirability of protocol and will make adherence to this specification a condition of grant or contract on all archaeological fieldwork that they fund. This will cover research projects, rescue archaeology and projects where the developer is the Scottish Executive (e.g. trunk roads). As with general developer funded work, tenders should reflect the intention to adhere to the specification.

1.3.3 Archaeological contractors working on Permitted Developments

Statutory undertakers may not require planning permission, but they are still expected to follow central government planning guidelines. This means that the LA archaeologist should be consulted for advice on the development. This type of development will be treated the same as all other developer funded work and the LA archaeologists will expect any archaeological data generated by such project s to comply to the general specification. In practice many large infrastructure development organisations have well developed guidelines for best practice, which would include taking the advice of LA archaeologists on the appropriate format for archaeological data.

1.3.4 University Researchers, Local and National Societies & Private Individuals.

It should be recognised by Universities, private researchers and local and national societies that their work is highly valued by the wider archaeological community. This work is often structured in ways specific to an individual research project and can sometimes represent the hardest data to integrate into the existing heritage dataset structures. Research projects funded by academic bodies most often reach full publication, however the timescales involved in this can mean that valuable archaeological information, or even knowledge that the project exists, can remain hidden from other academics, commercial archaeologists and the public for a number of years and, in some cases, decades. In order to ameliorate the problems of idiosyncratically structured datasets and non-publication or reporting or projects for long periods of time, adoption and adherence to ASPIRE should be vigorously promoted amongst these sectors as best practice.

Academics and University staff, who have a responsibility for teaching best practice in archaeological fieldwork, need little encouragement in pointing out the uses and value of such a protocol as well as ensuring their own projects comply with it. If they receive funding from HS, compliance will be a condition of the grant. The Archaeological Data Service (ADS) act as advisors, approving projects for funding, for the Arts and Humanities Research Board (AHRB), NERC and various other funding bodies. The ADS will expect any new archaeological field project in Scotland seeking funding from these bodies to specify ASPIRE as the most appropriate protocol for informing the rest of the archaeological community in Scotland of their event and summary results.

Many private individuals may not reasonably be expected to ensure that their report of, e.g. a single lithic find, complies exactly with ASPIRE. However there are a significant number of very active private individuals that regularly report new archaeological information, they may welcome the opportunity to comply with the current archaeological best practice and should be encouraged to do so. This may be best facilitated by organisations such as the CSA, RCAHMS and HS who all have a recognised role in outreach and public education.

1.3.5 Archaeological work under the auspices of other bodies

It is expected that other archaeological organisations, such as the CSA, SAS, NTS and the Forestry Commission (Permitted Development) will adopt ASPIRE as their own best practice requiring it as a standard condition of work they fund. Council archaeologists will be expected to ensure it is adopted in respect of any council funded work.

1.4 Copyright and Freedom of Information

All information, i.e. event report summary, new site information (including GIS data), submitted via ASPIRE will become copyright of the data curator (SMR/NMRS) at the point that it is integrated into their datasets. Naturally, all full archaeological reports, synthesis and ancillary data that would comprise an archaeological archive will retain its original copyright. If for reasons of commercial sensitivity summary archaeological information or the occurrence of an archaeological event are required to be confidential the normal procedures will be followed, with an appropriate embargo on that information being agreed with the data curator. For DC work, any information submitted in support of a planning application or to discharge a planning condition are automatically in the public domain.

2 Protocol structure

This specification is created and curated by the SMR Forum Technical Working Group with contributions from HS and others. The RCAHMS have agreed to host this document for general access. This means that, as well as being available from each SMR, the most up-to-date version of this document will always be available via the appropriate RCAHMS web site (or www.aspire-resource.info this domain name is currently being held for the APT by 7thSin digital and the site is under development).

It is acknowledged that the requirements specified in this document are necessarily prescriptive. The standards and requirements have been created in a spirit of cooperation encompassing all archaeological sectors that will be affected by them, contractors, researchers and curators. In keeping with this spirit of cooperation it is intended that as new issues regarding formats, data typing and archaeological field techniques arise all those expected to comply with the standards will be consulted through their representative bodies on changes to the specification. Queries regarding the current specification should in the first instance be directed to the curatorial body responsible for the fieldwork (e.g. LA Curator, HS, NTS etc.). Suggestions for alterations and enhancements should be formally submitted to the chair of the SMR Forum.

It is expected that the specification detailed in this document will change on a regular basis. It will be the responsibility of the data originator to ensure that they are adhering to the most current version of the specification. To facilitate this a document history is attached as an appendix with each document revision assigned a number and a date. When submitting data it is imperative that the specification revision number is clearly associated with the data (see Section 9). For help in ensuring that you are using the most up to date version see section 2.1.1

This document is designed to be used in such a way that each element of archaeological reporting can be specified with a high degree of rigour. Where the minimum required fields, data types and meta-data for tabulated data (or databases) are specified they will appear in this document as embedded spreadsheet tables allowing them to be extracted directly into a database as a template (using dbf format and/or as delimited text files), in the PDF version of this document this will not be possible. MS Word versions of the document will be made available and sample databases (in MS Access, SQL and Dbase formats) will be available as downloadable appendices. Similarly, GIS specifications which utilise tables and legends will have sample tables and legend files available (ESRI ArcView .avl, MapInfo). For a full list of available templates see Appendix 8.3

2.1 Implementation Quick Summary

All that requires to be submitted to the SMR(in the first instance) and NMRS to comply with ASPIRE are:

ASPIRE Database (or spreadsheet)
Event Record
Site Record(s)
Metadata (which includes info on reports or other data generated by this project)
Completed Checklist table
ASPIRE GIS coverage (if GIS was used in your event)

2.1.1 ASPIRE Forum

It is likely that a number of questions will arise during your implementation of this protocol that have not been directly addressed by this document. It is also likely that you will not be the only person to have pondered a particular issue. An on-line ASPIRE Forum – an email mailing list – will be created to allow you to ask your questions immediately and have them answered by a member of the APT or other by another user. The forum archives will build up to create a record of Frequently Asked Questions (FAQs) that you will be able to search for answers. This mechanism will also be used by the APT to post important info to keep all users of the protocol informed.

2.1.2 How you produce your data.

It is important when producing new information of any kind that attention is payed to using the right tool for the job. This means that, for example, data is presented in a database, text in a word processing document etc. The following are the basic principles that should be adhered to wherever possible:

Data in the form of a list of records. This data should be presented in a relational database. Examples of this might be a gazetteer of sites or a list of finds. This information should not be presented as a text list as in a word processing document or as structured cells as in a spreadsheet. Spreadsheets are designed to hold financial information (this is why mathematical and financial formulae can be specified in cells). Some spreadsheets do offer some database functionality (although do not allow relationships between tables to be specified, i.e. they can only handle ‘flat files’), if they are used to hold data the data should be exported to a database format such as “dbf” so that they can be imported into a database system. It is far better to use a database in the first instance. Spreadsheet templates are supplied by ASPIRE only for those who do not have access to any database system (such as found in Microsoft Office, MSAccess) rather than for those who have habitually used them.
Purely numerical information that does not rely on records of more than one field or require relationships to be specified between tables (lists) can be presented in Spreadsheet format. This form of information is not often required or expected in the reporting of archaeological events, although it may comprise parts of a project archive.
Geographical information, such as vector maps showing the location of events, trenches and even features as well as point data show site locations, should be presented in a Geographical Information System (GIS) format. It should be noted that Computer Aided Design (CAD) systems are designed for technical drawing, to produce, for example, blueprints for a car engine or a skyscraper. Because they are not specifically designed as GIS there GIS functionality and formatting are often not ideal, although as with databases and spreadsheets some CAD systems includes some GIS functionality including geo-referencing. Where possible CAD systems should not be used in favour of GIS. Where a commercial contractor receives design data from a developer, e.g. a road design, it is their responsibility to convert it for the appropriate application. Fortunately many developers and engineers use GIS to handle their geographic information. Where raster maps are being submitted they should be appropriately georeferenced.

It is very important to remember that ASPIRE is a protocol designed for reporting archaeological events and new archaeological information. Its primary objective is to simplify and integrate data exchange between all those involved in archaeology. It is NOT designed to replace standards and good practice in terms of field recording or in archiving your project.

3 Event Reporting

3.1 Introduction

Traditionally a small summary of all fieldwork that takes place in Scotland is reported to the wider archaeological community via Discovery and Excavation in Scotland (DES). This is a paper publication with limited space for each entry and a time cycle from field work to publication of the summary which can potentially run over a year. An additional reporting method – Online Access to the Index of Archaeological Investigations (OASIS) – has been agreed in principle (SMR Forum/RCAHMS) as the primary method for reporting new archaeological fieldwork to SMRs/NMRS in the future.

(NB OASIS is not a replacement for DES, the two systems have different audiences and objectives as well as different levels of data. If reporting to DES is a requirement specified in an SMRs Standard Conditions, this will not change. OASIS will be an additional and complimentary requirement, with concomitant cost implications for contracting units which they must include in tenders).

The OASIS system, hosted by the Archaeological Data Service (ADS) is enjoying considerable interest in England and Wales and its usage, functionality and significance as an archaeological tool are all on the increase. A version of the system tailored for use in Scotland is hoped to be available on-line for general use before the end of 2006. At this point the ASPIRE event reporting mechanism will be OASIS and the ASPIRE event table in this document will be deprecated.

3.1.1 Before OASIS

The ASPIRE protocol is designed to integrate into the forthcoming on-line event reporting system OASIS. To this end the top-level event reporting data specification is designed as subset of the, far richer, structure incorporated into OASIS. Prior to OASIS becoming available (in its Scottish incarnation) top-level event reporting should be in the form of an ‘event’ table which contains the core data necessary to create a summary record of the event. This table is specified in this section and is available in the template database. OASIS assigns a unique number to your event, prior to using OASIS it is important that each event submitted via ASPIRE has an identifier (e.g. AnyUnit Ltd. Project 25.1 - AUL25.1 or Oldton market square 2003 - OMS03). This is the ID that will be used to reference all the other data submitted to make the reporting fully ASPIRE compliant. There is no guarantee that such codes will be unique (nationally) and it will be the responsibility of the event report curator to assign a unique ID to the event for integration into their systems.

The data structure of the events reporting table, including its relationships to other tables is available in the appendices and the Look Up Tables used can be examined in any of the template databases.

3.1.2 After OASIS

Once the Scottish version of OASIS is up and running and fully tested, i.e. stable and robust, this will be ASPIRE’s primary method of lodging the event report. It will be very similar data an originator will be asked for to report an event, but they will be asked to enter it on-line via the OASIS system. It is very important though that the number assigned to the event being reported (by the OASIS system) is always referenced in the appropriate place in the additional submitted information (i.e gazetteers, new site reports, excavation reports and GIS coverages). For example, when an event area is polygonised the field in its attribute table relating to the OASIS ID must have the OASIS event number. At this point it will also be possible for the attendant digital objects, report documents, survey databases, GIS coverages etc. to be uploaded to the OASIS system rather than being emailed or posted on disc to the SMR/NMRS. As the SMR/NMRS will have access to your record on the OASIS system this will become the favoured mechanism for physically exchanging the data. This has the added benefit of allowing the files to become part of the OASIS ‘grey literature’ library and immediately available on-line (subject to public release being approved and any embargoes required – this is subject to the individual license agreement between each contracting unit/researcher and the ADS). Units are encouraged to make their ‘grey literature backlog available in this way also and a template table for the required meta-data is included in the ASPIRE specification. This service is currently free, but as it may be necessary for the ADS to make a nominal charge for this in the future ASPIRE does not apply to data of any kind prior to its adoption, how organisations and individuals deal with their backlog of inaccessible archaeological data is not covered in this document.

Events with a geophysical survey component should be submitted in the normal way, however it is hoped that Scottish geophysicists will be able to benefit from a specialised geophysics reporting module to be designed and integrated into OASIS at some point in the future.

4 Site Reporting and Gazetteers

A careful distinction should be made in using the ASPIRE protocol between additional information on a previously recorded site and an entirely new site.

The template database is designed to allow the submission of both these types of data.

Please remember that the data that is submitted via ASPIRE is summary information (of a similar depth to that held by the NMRS and SMRs) and ASPIRE does not facilitate the full reporting of very detailed site information, this should continue to be submitted in the form of an appropriate site report (s). The summary records allow other archaeologists to keep up to date with new sites and new sites information as well as directing them to the appropriate sources for the more detailed site reports.

The data structure of the sites reporting table, including its relationships to other tables is available in the appendices and the Look Up Tables used can be examined in any of the template databases.

Many archaeological organisations generate gazetteers of sites for inclusion in, for example, Desk Based Assessments or EIAs. The ASPIRE template database has a reporting function that allows these gazetteers to be generated directly from the database instead of being laboriously written out in a word processing package. This makes it more attractive for project site information to be entered directly into this database rather than being filtered through intermediate recording formats. Although the ASPIRE database itself should not be developed it is perfectly acceptable for the core data structure (tables and relationships) to be used as the core for more sophisticated data management, such as the addition of fields detailing mitigation proposals.

Every event should have at least one site record, unless it was event that generated absolutely no new sites or new information on existing sites. This is an unlikely scenario. An excavation event on a previously unknown site, for example, an excavation of archaeological features uncovered by an earlier evaluation event should have a site record for the features as well as a record of the event.

Complex or distributed sites should obviously have an associated polygon in the ASPIRE GIS layer, however it is possible to enter multiple coordinates for a single site in the ASPIRE template database, this is further explained in the Data Dictionary entries relating to subsites.

5 ASPIRE GIS

The GIS component of ASPIRE is a single coverage. The ASPIRE GIS coverage is a polygon layer (point layers are not required as they can be generated from site and event tables giving grid references). If you are reporting an event or a new site and the only locational information you are submitting is a centred point, then this information should be submitted via the event or site forms. This single layer is designed specifically to hold event and site information together, as a result it is of crucial importance that the attribute table associated with each polygon is completed in its entirety.

Please remember that inaccurate or uncertain site or event extents can still be reported via this coverage. For example the use of the various codes for the attribute table fields (e.g. SOURCE, TOLERANCE) would allow a site that was simply observed in the field and sketched on a map later to be submitted via this layer just as easily as a polygon generated by a DGPS survey. The intention of this layer is to allow the reporting of all kinds of geospatial data rather than specifying exactly how it is originally generated – which is beyond the scope of ASPIRE. This requires a clear understanding that digitally generated and submitted data is not necessarily accurate data, and that the additional fields in the ASPIRE coverage are designed to indicated just how accurate the data might be and therefore inform future users of the data.

As with the event and site database tables the GIS coverage is not intended to facilitate the reporting of very detailed site plans etc. in GIS format. It is not intended to allow the submission of “feature” level data. This coverage stops at the level of trench extents, more detailed information should be submitted as normal. This is the reason that there is no polyline coverage, any element that requires specification by polyline is by definition more detailed than that required by the ASPIRE protocol. The only possible exception to this would be a linear feature such as a road, in this event the site specification should still be in the form of a polygon, which can if necessary be generated as a buffer of a polyline layer.

The attribute table of the coverage, available in the appendices, contains a number of fields that might not normally be included for internal use within an archaeological information, but which are essential for the integration of the data into national and regional datasets without duplication of effort. This is based on the principle that the people best placed to specify the source, accuracy and nature of a particular polygon are the people who generated it rather than this being done retrospectively.

The data structure of the attribute table is available in the appendices and the Look Up Tables used can be examined in any of the template databases.

The ASPIRE legend is specified in ASPIRE.avl (this will have equivalents created in other GIS formats as required). This legend is not intended to be a universal legend that should be rigorously adhered too by everyone in archaeology, this would be impractical and undesirable. The NMRS, HS and SMRs all use their own legend formats as do contracting units. The ASPIRE legend, however, SHOULD be used when moving data from one organisation to another where that information is in the ASPIRE GIS format – this allows all users to immediately understand and use the information without decoding an individual organisations legend format.

If your organisation does not have a standard legend format, you could consider adopting the ASPIRE legend for GIS data that you intend to share out with your organisation.

If you are a private individual or an archaeological society with no access to a GIS system you geospatial information should be submitted as normal (paper or scanned maps/plans) and the names of these documents should be noted in the Site/Event database forms and in the checklist field for associated files.

Original Briefing Note

Briefing Note: Accessing Sites and Monuments Records, Meeting held in Glasgow, 12^thNovember 2004.

Representatives from the following organisations attended:

SMR Forum – (Technical Working Group), ARIA, RCAHMS, AOC, SUAT, CFA, GUARD, Firat, Headland, Rathmell, Jacobs Babtie. (HS intended to be represented, but were unable to attend due to unforeseen circumstances, as were Addyman Associates).

The first part of the meeting consisted of SMR, HER and FISH demonstrations and a discussion on how the three current major projects/developments on handling archaeological data, OASIS, FISH XML and PastMap 2 relate to each other. Data exchange and interoperability were identified as the key themes and XML and data distribution as the key implementation technologies. It was agreed that in order to fully reap the benefits of these projects a more coherent approach to data structure and data exchange for developer funded work would be beneficial to all.

A strategic objective was identified: Archaeological data should be gathered, structured and deposited in such a way that it is immediately usable and deliverable (without recasting, restructuring or re-keying) by both the Local Authority Curators and the RCAHMS. This benefits all parties, depositors, curators and users of the data.

Recent meetings amongst the Local Authorities (SMR Forum/ARIA) and between the Local Authorities, the RCAHMS and Historic Scotland have reached a consensus that for development control (DC) work a single nationwide set of standard conditions should be specified for data structure and format. These would be enforceable by LA Curators where the data is generated in support of a planning application or for the discharge of a planning condition. For non-developer funded work, such as that funded by HS, the same set of standards should be required as a condition of grant or contract by the commissioning body. This preferred data structure and format should also be promoted as best practice amongst non-commercial archaeological organisations that generate data such as Universities and local/national societies.

Given that the adoption (and enforcement) of such a set of standards would have direct implications for the working practices of commercial archaeological contractors this meeting had been called to gauge their opinion and gather suggestions. Therefore the second part of the meeting consisted of an open discussion of the issues that might be raised by a set of standards. Input from all contractors was positive with a general agreement that the strategic objective was desirable and that standard conditions would help to achieve it. It was further agreed that if enforced nationwide on all DC projects this would create a ‘level playing field’ with all contractors being able to cost and implement the conditions equally.

The level at which standard conditions should specify data was discussed and again there was general agreement that low level specification, e.g. down to data field and data type level or to symbol definition level, would be possible. It was further agreed that geo-spatial data (especially digital) could be equally rigorously specified and that the geo-spatial standards working group (consisting of RCAHMS/SMR-HER /Contractor representatives) standards should be incorporated into the proposed general data standards. Similarly, existing best-practice and de facto standards (such as MIDAS, Inscription, Gmap and the NMRS Thesaurus) should be incorporated so that there are not competing or conflicting standards to work to. In this respect the specification of standard conditions can be seen as the collation of a number of more loosely specified and enforced standards into a single, more rigorous item.

It was noted that a pragmatic approach should be adopted for enforcement regarding the scale of projects, for example it would be unreasonable to specify the use of Differential GPS for a survey for a single house development, but it may be essential for a wind farm development. However, in either event the way in which the resulting survey data is structured and deposited could be covered by the same set of standards. All LA Curators present agreed that flexibility and ‘common sense’ would be required in the implementation of the data standards.

The final outcome of the meeting is that there is now a consensus on the desirability of standard conditions for data structure and deposition between HS, RCAHMS,LA Curators and Scottish Archaeological Contractors – between them, these bodies commission, create or curate the significant majority of new archaeological information in Scotland. Such standards should be enforced in the context of DC and nationally funded work and required and/or promoted as best practice in all other archaeological work. The standards should specify data structure as tightly and at as low a level as is practical.

The agreed action points for the meeting were that the SMR Forum Technical Working Group will produce a draft copy of these standards for circulation by January 2005, and that those organisations attending the meeting agree to comment on the standards (there are a number of other organisations, not present, who should be offered the opportunity to comment, such as the CSA, SCAUM, NTS, SAS etc). It is hoped that these proposed standards will be agreed and operating nationally by spring 2005.