Internet Archaeol. 7. Gray and Walford. A sample SSD

A sample SSD

We present below a sample structured site description showing the XML markup and some specific comments on it. Although this information is intended to be parsed by a computer, it is text-based and capable of human interpretation (that it was prepared and formatted by a human makes this easier). In practice, this SSD could be embedded in or attached to a report along with the Dublin Core metadata which described the report itself.

  <?xmlversion="1.0"?> 
 <site provider="example" sitecode="IA99" version="1">
      <name>Brown's Farm, Long Heslington</name>
     <size type="area" unit="ha">1.2</size>
     <invtype>evaluation</invtype>
    <location scheme="osgb">SJ41625978</location>
     <dating scheme="code">ba med</dating>
      <feature>
         <type scheme="rchme-tmt">RRF:Cemetery:Cremation Cemetery</type>
         <dating scheme="code">ba</dating>
         <feature>
             <type scheme="rchme-tmt">RRF:Burial:Cremation Burial</type>
         </feature>
         <feature>
             <type scheme="rchme-tmt">RRF:Burial:Cremation Burial</type>
              <find>
                 <type scheme="none">Comb</type>
             </find>
         </feature>
     </feature>
     <feature>
         <type scheme="rchme-tmt">Domestic:Settlement</type>
         <dating scheme="crange">12:13</dating>
         <feature>
             <type>Domestic:Dwelling:House</type>
             <qualifier>timber-framed, clay-walled, thatched</qualifier>
         </feature>
         <feature>
             <type>Unassigned:Drain</type>
         </feature>
         <feature>
             <type>Unassigned:Boundary</type>
         </feature>
         <feature>
             <type>Agricultural:Stock Enclosure</type>
         </feature>
     </feature>
 </site>

Points to note

There are several points worth noting in this example:

Tags can be nested. This allows features and finds to be grouped in a logical way and makes it straightforward to express the concept of a find being contained within a feature, and of sub-features.
We have used tag content rather than attributes to hold key values. This is primarily to make the description easier to read, and to make a distinction between the content data, which may either be free text or from a large controlled vocabulary, and attributes, which will generally have a small number of possible values.
Most of the tags are optional. A fixed scheme that forces the specification of unknown or irrelevant data makes the automated searching and indexing process more complicated. It is possible to attach a confidence value to descriptions or dates which are uncertain.
Provision is made for different schemes for type, dating, location, size and so on, to reflect the preferences of authors. There is obviously a benefit to the community in adopting common standards where possible, though for some items (size, dating, location) translation between schemes is feasible. Translation between different thesauri for feature and finds types is a significantly more involved task, so adoption of common standards here is appropriate.
There are mandatory qualifiers for provider and site/report code in order to give every site a unique identifier. A version number is provided to make it possible to distinguish a newer version of the description of a site, should it be revised.

A few notes on terminology are relevant. We have used 'feature' as the primary element description tag, rather than 'context' as this structure is not intended for recording at the context level. Instead, the intent is to record the 'most interesting' facts about the site in a structured manner. As a consequence, it is not a replacement for traditional data repositories, and doesn't contain all the possible information that could be recorded about a site. The design criterion has been to include the most likely grounds for searching and indexing, as a trade-off between compactness and completeness; like metadata, this information is ultimately just a pointer to a full report.

The definition of 'interesting' is flexible, and constitutes the kind of material that would be highlighted in an abstract, or which the author would particularly mention to his or her peers. Obviously, commonplace or standard features of sites need not be included. A general <find> entry for 'animal bone' is probably redundant unless there is something unusual about the presence, quantity, location or type. It may be relevant to note negative information (i.e. the absence of certain kinds of finds or features) in some circumstances.

The other information which would be better recorded in a site database is a precise description of the relationships between elements. The SSD structure that we propose does not provide a means to report relationships between contexts. Instead, it is intended to provide a general outline of what there is, and possibly where it is.

Issues to be resolved

This should be seen very much as a work in progress. There are plenty of issues to be resolved, for example:

Should a description include any methodological information? That is, should features inferred from geophysical data be marked as such?
How much contextual information about site location could be usefully specified, i.e. whether it is urban, hilltop, by a river, underwater etc. This is potentially of interest to data users, but requires the selection (or possibly development) of suitable vocabularies.
Is it useful to specify the shape of items in a general sense? A vector graphics addition (see below) would provide a more precise representation, but without this, what general terms should be used to describe object shapes?
Confidentiality of site locations. There is obviously some concern about making the exact locations of sites available on the web. There is no simple automatic solution to this. The accurate location data could obviously be omitted and if the site proved to be interesting on other grounds, the report author or original contractor could be contacted. An encryption-based scheme is also a possibility but involves administrative overhead.

Future developments

It is clear that much work lies in the identification of suitable controlled vocabularies, and that wider consultation with potential users is necessary. Other developments could include (in descending order of priority):

A search engine (and 'web crawler') tailored to the SSD data format.
Simplified site plans. Embedding XML vector graphics tags in an investigation description could provide a pictorial representation of the position and extent of features. Because of the compactness of the XML representation, the plan would be available on the search engine; the items (features or findspots) relating to query terms could be highlighted.
A user-friendly interface that will present the user with, say, a set of simple forms and then generate the SSD. This could be done by providing an applet which users could run locally, or via a web-based interface.