Development work on the new thesaurus management system is progressing well, albeit more slowly than anticipated. The initial stages of the development on the database and the SOLR/search interface went smoothly, as did the translators’ screens and functionality, which were completed and submitted for user testing before Christmas. Feedback was generally positive. Work is now focused on producing the suggestions screen.
As with all tasks, one part of the development team focuses on UI development, while the other is constructing the database and Rest-based service architecture required to handle all of the data requests and posts. The team has also been working in two week Agile sprints in order that the technical development may progress more quickly.
The basic and innovative idea behind the suggestions screen is that the user can bundle a number of proposed changes together as one suggestion, since a change to one term often has a knock-on effect on another. Another key feature of the design, which is a departure from the initial specifications but which was added to enhance the user friendliness of the system, is a treeview controller for navigation around the hierarchy. This is the first time that the team has attempted anything similar with such a complex data object.
The suggestions screen has been implemented in such a way that users make a copy of the thesaurus for manipulation before submitting the changes as a suggestion. Suggestions can then be collated.
This work has required the data team to upskill in utilising LINQ to XML.
Much of the user interface has been implemented using AJAX scripting to minimise post backs and maximise the user experience, and using restricting lists in real time.
Once the suggestions subsystem is completed, work will commence on the edit and administration subsystem.
The edit screen will interact directly (via service calls) with the database itself and changes will be made to a working version of the thesaurus. All terms and relations are to be versioned and this is an integral part of the database model.
The complexities of the edit screen are in some ways more straightforward than the suggestions screen, but there is a large set of validation rules and checks that must be performed against core terms in order to keep ELSST and HASSET in alignment. Of course, some of this will have to feed back to the UI so that the user does not submit an edit, only to be told that it is not allowed. Sensible UI validation with AJAX-based service calls to perform checks will have to be implemented to avoid this situation.
Development to date has primarily focused on ELSST. Work on HASSET screens will start later, and will hopefully prove straightforward.
Running parallel to the UI work is a separate strand of work to create SKOS-ELSST as we have already done with SKOS-HASSET. This will once again be served using the Pubby interface. SKOS-HASSET is available to view at http://lod.data-archive.ac.uk/skoshasset