The following three-stage scenario is based on the technologies discussed throughout this article. The scenario is a summary of the author's vision of how archaeological data can benefit from the adoption of web services as the discovery and transport mechanism, and portal technology as a means to exploit/expose these various data sources. In many ways this scenario is an up-dating of the vision that Henrik Jarl Hansen had for an information structure for European archaeology more than ten years ago (1992). It also takes interoperability a step further than ARENA and represents possible further development of a European information network.
If a model such as that outlined above had been in place before work on the CREE project had commenced, development of the HEIRPORT lite portlet would have almost certainly taken a different course. Primarily, one could envisage that communication between the portlet and the core ARENA or HEIRPORT system could perhaps be avoided altogether. The portlet could communicate directly with the UDDI registry to retrieve a list of available data sources (for example the ARENA partners) rather than depending on a static list of targets as is enforced by the current Z39.50 model. From here, the portlet could send queries to each of the data sources, returning results as a collection of XML formatted result sets.
In a similar fashion, the next generation of information portals, successors to the ARENA or HEIRPORT portals, could benefit from this network of archaeological data. Indeed, one of the most frustrating aspects of the development of these systems was to orchestrate the deployment of the Z39.50 targets among the various partners involved. By using a dynamic registry, the frustration of 'target deployment' could perhaps be replaced with the more progressive element of 'target discovery'. Partners could 'opt-in' to the scheme by exposing their datasets as and when they see fit, with the knowledge that these would be available immediately. The portal could incorporate discovery by allowing the user to request datasets pertaining to specific attributes as defined in the resource descriptor published to the registry (e.g. where the dataset is located etc.).
The model could be extended to incorporate various security and authorisation checks as outlined in the recent Web Service Security (WSS) (Glossary) specifications. This would allow the concept of user 'roles' to be integrated within the network. With this in place, existing collaborative ventures, such as the Online Access to the Index of Archaeological Investigations (OASIS) project, could make use of the same mode of transport and body of data as the applications mentioned above.
The OASIS project allows fieldwork documentation to be created by archaeological units and checked and validated by heritage managers without the need for extensive printing and posting of reports. It also allows for the final publication of material that until now has remained largly inaccessible as grey literature. Using the scenario proposed above, a record could be created by a local fieldwork unit and uploaded to a Web services enabled OASIS repository via a portlet interface. Depending on the status of the record and the role of the user, this record could be requested for amendment and validation, either via the same or similar portlet interface or perhaps a local application, and returned to the system. At some point, the same record could be marked as 'public' where it would automatically become available for request by the general public.
As with any 'utopian' design, there are several real factors that could potentially inhibit the interconnected system outlined in this discussion from achieving its goals. As previously mentioned, a coherent and standardised metadata schema is essential for the system to work. Although MidasXML is a promising candidate for this, there are still those whom are either a) not convinced the schema is sufficient for the purposes of archaeology, or b) those who think it is overly complicated. In the end software developers should be the only people concerned with the complexity of an XML schema. Indeed, if the information can be structured in a standardised manner, no matter how complicated that structure may be, it is the job of the developers to create an application that can find, extract and present information to the user in a more appropriate format. On the other hand, if the structure is too simplistic, there is the danger that resolution of archaeological data will decrease, ultimately leading to data loss. For example, although the 15-element Dublin Core metadata schema has been employed by a number of archaeologists, including the ARENA project, to represent their data, there is no 'hard-and-fast' way to distinguish temporal and spatial data from one another. More often than not, both these elements are merged into the single term 'DC.Coverage'. While various parties may extend upon the DC.Coverage element (e.g. DC.Coverage is often split into DC.Coverage.spatial and DC.Coverage.temporal), the fact remains that for an automated or interoperable system to function all parties must adhere to a specific rule for tagging the data.
Although this model could ultimately save considerable amounts of time for various archaeological research and data-processing, the resource cost to implement a system such as this could well be high in terms of time, technical knowledge and, naturally, the required funding.
There is also an issue regarding who would administer such a system. The model does allow individual data suppliers to expose their datasets as Web services themselves, which, at its basic level, would suffice. However, the element of discovery, which is perhaps the most exciting factor within the model, requires directory services such as UDDI. It is here that controversy surrounding responsibility for the maintenance of this type of service may well occur.
Finally, it must be remembered that the proposed model is largely based on observations of technology gained from specific literature, rather than as a result of direct working experience with each and every component. Although the technology says it can do all this in its publicity, it may well not perform as expected in a live system. Therefore, it would make sense to construct a mock-up system which could utilise the required technology. Issues such as load testing and, perhaps more importantly, scalability could then be investigated. Despite the hurdles that remain to be cleared, the pathway to a shared European information infrastructure remains achievable. The technologies discussed in this article can provide the building blocks for the further integration of European heritage information.
© Internet Archaeology/Author(s)
University of York legal statements | Terms and Conditions
| File last updated: Tue Sep 27 2005