The Heritage Exchange Protocol (HEEP) has been designed to facilitate the querying, amalgamation, and of course the exchange of heritage data between heterogeneous data sources such as SMRs (Sites and Monument Records), their successor HERs (Historic Environment Records) and national archives such as NMRs (National Monument Records), and Listed Buildings Database, among many others. This document is authored by the Forum for Information Standards in Heritage, (FISH), a consortium of UK-based heritage institutions that oversees data standards and their implementation. Within the scope of this document, the term 'heritage' is used to describe archaeological and monument-based information traditionally described by the MIDAS standard.

While FISH is UK based, the HEEP has been designed for use within the international heritage community; no element of this protocol precludes its use in Europe, the US and elsewhere.

This specification defines a syntax for the request and delivery of heritage data, and is intended to provide the foundation of a Web Service for heritage data. A Web Service provides a means whereby data can be queried and exchanged, independent of the backend storage medium, application platform, and hardware infrastructure. To make use of the HEEP, Developers must simply ensure that their client and server applications can query and return data in the prescribed XML formats.

XML is used to query the content of HEEP-enabled servers, to deliver their content, and to provide service-level metadata. The schemas used within the protocol are defined within this document, and also available online at: http://oxarchdigital.com/fish/hep/0.1/schema/. Example xml documents used within the protocol are available at: http://oxarchdigital.com/fish/hep/0.1/examples/

The protocol allows queries to be formed against all elements of the heritage record, including spatial searches such as bounding box, buffering, and other spatial functions.

Queries to a HEEP server can dictate the number of records returned, as well as the granularity of the data. This document details what essential functionality must be in place to create a HEEP-enabled server and client application. The protocol allows a HEEP client to obtain the capabilities of a HEEP server with the intention of providing a scalable HEEP service that retains all elements of backwards compatibility. The protocol also includes a version negotiation scheme to facilitate exchange between clients and servers of differing versions.

A primary concern intended to be addressed by the creation of the HEEP was the ability to amalgamate heterogeneous heritage data sources. The HEEP supports the creation of distributed heritage networks, with each node in the network responsible for only its content. A HEEP-enabled server can therefore act as a cascading heritage server, amalgamating the content from subsidiary HEEP servers for delivery over the Internet or institutional intranet.