This document summarizes experiences from developing an ontology about software in an agile manner through workshops. It describes holding workshops with various stakeholders to gather requirements, prioritize features, and begin populating ontology modules in an iterative process. The goals were to avoid lengthy conceptualization, get early results, and allow priorities to change based on examples discussed. This approach allowed for collaborative authoring without everyone needing ontology expertise and separating knowledge gathering from formalizing axioms.
All-domain Anomaly Resolution Office U.S. Department of Defense (U) Case: “Eg...
Keeping ontology development Agile
1. Keeping ontology
development Agile
Robert Stevens
BioHealth Informatics Group
School of Computer Science
University of Manchester
Oxford Road
Manchester
M13 9PL
Robert.Stevens@Manchester.ac.uk
2. 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
5. 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
6. 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
7. SWO people
• Andy Brown (Manchester)
• James Malone (EBI)
• Helen Parkinson (EBI)
• Robert Stevens (Manchester)
8. 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
10. Rules of Engagement
• No death by PowerPoint
• Actually get a workshop to do some work
• No Ontologising
• Show some early results
11. Workshop Attendees
THE BRITISH LIBRARY
Bioinformaticians
Bio-ontologists
Librarians
Software
Preservation
Data
Preservation
Service
Registaries
Workflow
Repositories
Publishers
Astronomical
Data Archive
Biology
Project Managers
12. 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)
14. Persona
Brenda theBrenda the
BioinformaticianBioinformatician
Brenda theBrenda the
BioinformaticianBioinformatician
Percy thePercy the
ProfessorProfessor
Percy thePercy the
ProfessorProfessor
Archie the SoftwareArchie the Software
ArchitectArchitect
Rufus the DigitalRufus the Digital
PreservationPreservation
ManagerManager
Rufus the DigitalRufus the Digital
PreservationPreservation
ManagerManager
Adrian the PhDAdrian the PhD
StudentStudent
Bender the RobotBender the RobotBender the RobotBender the Robot
Fergus the FunderFergus the FunderFergus the FunderFergus the Funder
Ollie the OperationsOllie the Operations
Support GuySupport Guy
15. Features Gathered
SoftwareSoftware
Source Code Location
Interfaces
Dependencies
Supplier
Version
Life Cycle
Configure/run
Parameters
Algorithms
Cost of Ownership
Platform
Licenses
Architecture
Data
16. 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/
17. 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
20. 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”….
22. 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
23. 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?
