Although the search page may seem to be the focus of this website, in fact the Cluster was designed with much wider possibilities in mind. To that end the system can be extended very easily to provide many more possibilities than one might first expect.

Web Services: Connecting to the Cluster

The Cluster uses Web Services and a query language to communicate with the constituent projects. However, this communication is not limited to within the Cluster: in principle any other resource could use the same system to interrogate either the Cluster or the constituent projects directly. Indeed the capacity is already in place for other resources to query the constituent project directly (although this is not yet publicly available), and the system design would also allow the Cluster itself to be queried. This should enable other projects and scholars to harvest the information gathered here.

Charter Widgets

One practical aspect of this connectivity is the possibility of creating 'widgets'. This draws on principles of 'Web 2.0', whereby instead of creating individual web pages which are connected only by links, one can create a small box or 'widget' which is displayed on other web pages but which draws its content from the Cluster or one of its constituent projects. (One of many examples of this is iGoogle.) For example, instead of 'cutting and pasting' information from eSawyer, the websites of the other three projects could simply include a widget which draws information about the charter from eSawyer directly. Scholars and students could even create their own 'dashboard' of widgets relating to Anglo-Saxon charters, and these could also be incorporated directly into Virtual Research Environments (VREs) or Virtual Learning Environments (VLEs) such as Blackboard or Sakai.

TEI XML Export and Interchange

Another important aspect of the project was a single Schema for all four constituent projects in XML according to a TEI Extension documented by an ODD.1 The XML that results from this TEI extension could be exported for use in other projects, and/or provided through Web Services, fulfilling one further use of TEI XML: for information interchange (for which see ). Developing a single Schema for all charters is an extremely complex and difficult task, but the Charter Encoding Initiative (CEI) is aiming to do precisely that. The schema developed here is indebted to the work of the CEI and will itself feed back into the CEI. If such a schema could be developed then this could be used for interchange across a very wide range of projects indeed.

Adding Projects

As should be clear from the preceding discussion, the Cluster is designed to be as flexible as possible in its arrangement. One happy consequence of this is that projects can be added (and removed) with relative ease: each new project must implement a Connector to the Cluster (for which see System Architecture), and some basic metadata such as the URL for the project's Web Service must be added to the Cluster's registry. The existing User Interface would probably need to be updated as well, to allow searching for the new data, but even without this the Cluster can connect to the new resource very easily. This model should allow the Cluster to grow significantly, incorporating more and more resources which relate to Anglo-Saxon charters and beyond.

Extending the Search

The Cluster's Search page is relatively simple and even 'old fashioned' in its appearance. It is much more complex than it looks, not least because the drop-down lists are all generated dynamically by quering the constituent projects, but the form still does not take into account the latest in Web development. For example, it has not 'auto-suggest' facilities which offer possibilities as you type, like that in Google's Search (among many others); it could also make use of faceted browsing like that of the the Centre for Recorded Music Sound File Search page, maps, and other elements as discussed in Interface Design. The fields that can be searched against are also relatively limited, as is evident from comparison of the User Scenarios and Searching the Cluster.

Some of these extensions could be implemented relatively easily. For example, more fields could be added to the search form simply by adding more entities and properties to the Logical Model, updating the Cluster and relevant constituent Connectors accordingly. Similarly, 'auto-suggest' and faceted browsing is simply a case of developing the User Interface and will require no changes to the Cluster itself. However, there are limitations to the searching which are imposed by the Query Language. For example, queries cannot move across series of relationships but can only consider two entities which are directly connected. These and other limitations are discussed further in Query Structure.

Beyond Charters

As discussed in Query Structure, the Cluster as a whole is designed in such a way that it does not depend on any single data model. In other words, although the application of this system is to Anglo-Saxon charters, the underlying model could be changed to represent any data which can be interrogated by the Query Language. In this way the Cluster could serve as a framework for other integration projects.

A further possibility is to generate the User Interface entirely automatically. At present the UI generates the drop-down list by querying the appropriate projects in turn, but it does 'know' which fields can be queried. Thus the list of 'Issuing Kings' is created 'on the fly' by querying eSawyer, the list of counties by querying LangScape, and so on, but the UI has programmed into it the fact that Issuing Kings and Counties are both valid search fields. It would be straightforward (although requiring minor customisation of the query language) for the Cluster to ask the projects what fields they know about and to construct the search form accordingly. In other words, rather than the UI 'knowing' in advance that input fields should be given for Beneficiary and Witness, it could ask PASE what the fields should be and display them accordingly.


For explanation of this terminology see §§23.3-23.4 of the TEI Guidelines. Back to context...