Last Thursday and Friday saw the second of our two workshops held in Manchester. The main aim was to test the ontology – to determine whether the priorities determined at the first workshop have been modelled effectively (to a limited extent – the ban on ontologising was only partially lifted) and are still considered important. We plan to give a more detailed write-up of some parts of the workshop, but for the meantime, here is a quick summary.
The main activity was describing software – participants worked in pairs and collated the information necessary to describe a piece of software using the ontology. This was done in a spreadsheet with a column for each important aspect of the software (i.e., those features bought in the planning poker session in the last workshop, and which we’ve been using to build the ontology). Over the two days, we completed descriptions of over 40 pieces of software, ranging from email clients and Web browsers, to Taverna workflows, soil chemistry models, and Perl applications for biological data analysis. Critically, each session was followed up by discussions about the areas which proved hard to describe, and it was the outcomes from these discussions, rather than the descriptions themselves, which were the most valuable output from the workshop.
After our describing activities, we did a card-sorting exercise to revisit priorites. This was a simpler version of the planning poker from the first workshop, and was intended to see if, given the experience of actually describing software, the different aspects that could be included in the ontology were still considered as having roughly the same relative importance. We also revisited use-cases, this time gathering the real applications that participants would like to use the ontology for.
These activities showed that we are, on the whole, on the right lines, but also highlighted some other areas which need to be implemented. Of particular note were: the need to handle software packages/suites, the re-emergence of platform as an important issue (despite not being ‘bought’ last time), and the need to handle the different perspectives that come from different users (e.g., the input data for a Web server is different for the administrator than it is for a client).