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.

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.