Updating the overall architecture

Last time Mark and I got together to apprise our current progress on the search extender for use with IntraLibrary, we also reviewed the general architecture of the systems surrounding the repository. As with most things this creative and dynamic this was done with pen and paper over a copy of our previous design and it is only recently that I have had the time to formalise it. An image of this is here. There has been a few refinements since then and the following diagram I think gives a good overview of what we have at the moment and what **things** are involved.

There are still a few issues. On the upload side we would have loved to have had a go at adapting SWORD to take a metadata file as well as the LO. SWORD’s purpose is to ease upload of multiple objects to multiple repositories as Nick explains here. But what does the user do then if they are not uploading packed objects? Where does the metadata come from? This is particularly relevant in the use of intraLibrary.

The other question is one that has been floating around for some time. How do we authentic the actual download of the Learning Object. Unlike Research papers (shown here as a comparison, as the repository is duel purpose) there are issues and concerns about making learning objects accessible external to the institution. As a result of this the search interface is currently two interfaces rather than the one. One suggestion is that as long as the metadata is exposed individuals could enquire as to getting a copy of the LO via the authors/institution.

Current Streamline Architecture

Architectual model

As a new member of the team I thought it would be useful to produce an overall architectural view of the main workflow packages that are to be built as part of the streamline project. I produced a conceptual architecture model that identifies the key elements.  The final aim of the working system is to allow access to the streamline functionality via multiple mechanisms. Initially however user involvement will be via a Java based GUI developed by Dawn. Eventually a web-based GUI will be the way to go, once the interface requirements have been developed, tested and evaluated by end users.  The underlying areas of the system will be required to do some number crunching, e.g. the latent semantic analysis which will allow related search results to be displayed to the user.  Initially these components have been developed using C++ and Matlab due to the suitability of these languages for rapid mathematical programming.  The intention is however, to convert all the components into Java in order to provide ease of integration and allow the system to be opened up to third party application via web-services and a Java API. A prototype of a parsing algorithm (to be used for meta-data extraction) has also been developed in C++ by Elizabeth. In order to allow ease of translation a UML model of this prototype has been created.  This should also ease further development of the prototype up to a stage where it ready for translation and integration into the full system.