keeping ontology development agile

Keeping ontology development Agile

Robert StevensBioHealth Informatics GroupSchool of Computer Science

University of ManchesterOxford RoadManchester

M13 9PLRobert.Stevens@Manchester.ac.uk

Motivation

• Ontology development is long and difficult– Never really complete

• Getting the conceptualisations right is hard, because it’s hard

• Requirements change• The underlying science changes• The perfect is the enemy of the good• A counsel of perfection is a counsel of despair• Delivering early and often, changing as necessary

The Waterfall

Knowledge GatheringKnowledge Gathering

ConceptualisationConceptualisation

EncodingEncoding

EvaluationEvaluation

Spirals

Knowledge GatheringKnowledge Gathering

ConceptualisationConceptualisation

EncodingEncoding

EvaluationEvaluation

Elements of agile Programming

• Iterative and incremental• Evolving requirements and solutions• Self-organising and cross-functional teams• Short time boxes; rapid and responsive

development• Doing what is important first• Users embedded in the process and are first

class citizens• Test driven; regular and frequent builds and so

on

Experiences from the Software Ontology project and others

• A short, six month project to start a software ontology

• Provide a vocabulary to describe software used in bioinformatics analyses and more

• Centre around two requirements gathering workshops

• http://softwareontology.wordpress.com

SWO people

• Andy Brown (Manchester)

• James Malone (EBI)

• Helen Parkinson (EBI)

• Robert Stevens (Manchester)

Workshop Programme

• What do you want to say about software? – clustering exercise

• What questions do you want to ask about software in archives? – Clustering activity

• Use cases• Which of these features are most important?• The persona of our users• Describe some software…• Re-visit elements to re-prioritise and so on

Angels on the head of a pin

Rules of Engagement

• No death by PowerPoint

• Actually get a workshop to do some work

• No Ontologising

• Show some early results

Workshop Attendees

THE BRITISH LIBRARY

Bioinformaticians

Bio-ontologists

LibrariansSoftware

Preservation

Data Preservation

Service Registaries

Workflow Repositories

Publishers

Astronomical Data Archive

Biology

Project Managers

Flow of Events

• Develop Persona to drive other requirements gathering

• Gather an cluster features• Gather and cluster competency questions• Prioritise features• Describe some software (informally)• Develop axiom patterns for the ontology• Describe more software• Do each bit again (and again)

Persona Headings

• Age

• Background

• Dress Code

• Favourite food

• Work

• Story

Persona

Brenda the Brenda the BioinformaticianBioinformatician

Brenda the Brenda the BioinformaticianBioinformatician

Percy the Percy the ProfessorProfessorPercy the Percy the ProfessorProfessor

Archie the Software Archie the Software ArchitectArchitect

Rufus the Digital Rufus the Digital Preservation Preservation

ManagerManager

Rufus the Digital Rufus the Digital Preservation Preservation

ManagerManager

Adrian the PhD Adrian the PhD StudentStudent

Bender the RobotBender the RobotBender the RobotBender the Robot

Fergus the FunderFergus the FunderFergus the FunderFergus the Funder

Ollie the Operations Ollie the Operations Support GuySupport Guy

Features Gathered

SoftwareSoftware

Source Code Location

Interfaces

Dependencies

Supplier

Version

Life Cycle

Configure/run Parameters

AlgorithmsCost of Ownership

Platform

Licenses

ArchitectureData

Competency questions• What software works best with my dataset?• Does it do what I want or need it do data e.g. render a gif?• Which software tool created this data?• What software can perform task x?• Is it appropriate software for my task?• What are the primary inputs and outputs?• Is this software available as a web service?• What open source, maintained software can I use to process these

in this format?• Where can I get the software?• Is there a mailing list?• How and where has this software been used successfully in the

past?• http://softwareontology.wordpress.com/2011/04/01/user-sourced-

competency-questions-for-software/

Priority poker

• Estimate the cost and complexity of each feature• Attendees give effort of 0.5, 1, 5, 10, …, 40 and

negotiate• Each attendee has “money” to the value of half

mean effort cost of a feature• The attendees collectively “spend” money on

features…• The result is a priority list of those features the

collective are prepared to buy

Ontology Modules

Interfaces

Data

SWO

Algorithms

Licenses

Maturity

Objectives

OrganizationsVersions

Implementation route

Requirements

Priority Poker

Implementation of top

requirements

Evaluation

Requirements priorities change

• In workshop one “hardware platform” was not prioritised

• In workshop two it was

• Working through examples indicated that it was important

• Add some “doing” to the #”thinking”….

Populating the Ontology Modules

What we’ve Learnt

• Collaborative authoring doesn’t mean everyone writes axioms

• Not everyone has to be a trained ontologist• Can separate knowledge gatherring from

axiomatisation (esp. via spreadsheets)• Ontologising is important, but not all the time

and not for everyone• Priorities change• One can manage workshops to have everyone

contribute and avoid “wars of words”• Don’t try to achieve everything in one go

Questions

• What features and characteristics of an experiment must be recorded to enable replicability?

• What features and characteristics of an experiment need not be recorded to enable replicability?

• What questions would you like to be able to ask of a repository of experimental protocols?