AIMS

3rd Agricultural Ontology Services (AOS) Workshop 2002

1. Introduction

Eight members of the Agricultural Ontology Service (AOS) Launch Group met with 6 local ‘potential users’ of the AOS and 2 facilitators in the Plant Sciences Library of Oxford University on 24th January 2002 to look at some broad issues which the AOS might need to address in the early stages of its development. The theme of the meeting was ‘Shaping the to meet user needs’. The discussion in this meeting was to inform the next day’s committee meeting of the AOS Launch Group. The users were:

  • Stella Dextre Clarke, Information Consultant
  • Kevin Jackson, Deputy Chief Librarian, DEFRA
  • Ray Lester, Head Librarian, NaturalHistoryMuseum, London
  • Roger Mills, Librarian and Information Services Manager, Plant Sciences Library, OxfordUniversity (also the host and facilitator)
  • Geoff Pearce, IPTRID Network Coordinator
  • Ian Pettman, Data Handling Editor, oneFish Community Directory
  • Dylan Winder, Communications Manager, Rural Livelihoods Department, DFID

2. Structure of the Workshop:

The meeting was opened by James Brooks (Thesaurus Manager, CAB International) and Roger Mills. After introductions from those present, Johannes Keizer (Head, AGRIS/CARIS and Documentation Group, FAO) gave a PowerPoint presentation on the AOS. The original intention of the day had been to divide into 2 ‘breakout’ groups for discussion of broad topics, i.e. existing provision for resource discovery, and future needs; AOSservice provision; AOSstructure and management; and AOSusers and the tools available to them.  This was attempted in the morning. However, the meeting decided that a more general discussion of the issues was in order, and the afternoon session was essentially a ‘round table’ of all participants. (See Appendix for discussion points).

All participants were invited to highlight particular issues that they believe the AOSneeded to address if it were to be a successful project. This led to attempts to clarify who the AOSwas for and what it would deliver. The issues of effective and appropriate communication, and of meeting the needs of ‘users’ (a term potentially masking a number of different types of user) were underlined. The role of information managers as intermediaries between the AOSitself and the information services provided to end users was clarified. The points raised were listed (and, following the meeting, these were ‘grouped’ by theme in order to arrive at some conclusions and recommendations). Users were given the opportunity to make some final comments before the meeting was adjourned.

DRAFT Conclusions and Recommendations:

  • There needs to be effective communication and collaboration between its partners if the AOSis to succeed.
  • The concept of, and benefits from, ontologies in the agricultural domain(s) need to be effectively communicated and promoted to potential users of the AOS. The use of the term ‘ontology’ must be clear.
  • ‘Real’ examples of problems that the AOSwould address need to be found. How the AOSwould solve them differently and better than existing solutions needs to be established.
  • The AOS needs to clarify how important the end user vs the information professional vs the computer developer is to its development.
  • The AOS needs clear goals for the short, medium and long terms. A short-term goal could be to produce a pilot project to show the benefits of a simple ontology, whereas a medium-term goal could be for a more complex pilot, say, to show the benefits of merging ontologies.
  • The AOS must be multilingual, or at the very least, provide for multilingual access.
  • The AOS must have strategic and business plans to address its sustainability and the continuity of service that it will need to provide.
  • The AOS will need a clear organizational structure, and the issues of ownership and governance need to be addressed.
  • The AOS will need to address maintenance and interoperability issues.
  • The domains and sub-domains that the AOSwill operate for will need to be clearly identified. What subject areas do they cover (and what are their boundaries)?
  • The knowledge organization systems / sources (KOSs) in these domains and sub-domains, and in related subject areas, need to be identified and described.
  • The AOSneeds to create conceptual templates, say, for concept relationships.
  • The formal ‘languages’ that the AOSneeds, and how they are used, have to be identified.
  • Software tools are needed to handle the different components of the AOS.
  • Methodologies are required to manage the ontologies within the AOS.
  • The AOSneeds to address how it will interoperate with other ontologies and/or ontology services, e.g. in the fields of genetics and molecular biology.
  • Mechanisms are required to measure the effectiveness of the ontologies for the end-user.

Final comments from users:

  • This is a big and complex project.
  • The AOSis part of a process, with deliverables along the way.
  • Why do users not make better use of existing KOSs? (Answers as provided by surveys would inform AOSdevelopment).
  • Pilot projects would demonstrate benefits of the AOS.
  • Users could make useful contributions to AOSdevelopment. [Some participants signaled their intentions to become involved with the AOS. The AgStandards listserve would be a valuable means of communication about the AOS].
  • A suitable business plan would assist the process of obtaining funding. If the latter was not forthcoming, coordinated use of existing resources should be deployed in pursuit of the ‘building blocks’ of the AOS.
  • There existed several options to promote multilingual access to the AOS, e.g. devolved partner activity (‘local nodes’), non-English query interfaces with answers returned in English, translations of ontology ‘conceptual templates’, etc.

3. Appendix: Points arising from Breakout Sessions and General Discussion

  • What ‘service’ does the AOSprovide? What are the benefits? What does the AOSoffer to users? (Some users indicated that they were more interested in what the AOScould do to enhance information retrieval and access to resources, or to provide metadata, rather than in the details of ontology construction or structure themselves).
  • How is the AOSconnected to the resources / resource collections themselves?
  • Who are the (groups of) users of the AOS? Communities of use: Information professionals, programming developers, managers, academic researchers, policy makers, field workers, students, etc.; cf. AOSnot of interest to ‘end users’ but to those who serve them.
  • Do the AOStogether, do it ‘once’, and do it well; cf. AOSontologies will ‘evolve’.
  • ‘Tension’ between a universal scheme (complex, difficult to manage) vs smaller, locally appropriate schemes. Consider modular approach to development, and pilot projects in neighbouring subject areas for subsequent testing of ontology integration and/or merger and/or interoperability.
  • A project in stages might begin with a (KOS+ standards + ontology tools + models) ‘warehouse’ and deliver ‘building blocks’ (‘pre-ontology service’) for the subsequent implementation of the full AOS.
  • Experiment with, say, AGROVOC + CAB Thesaurus in a subdomain subset (e.g. forestry) as a testbed would clarify issues regarding handling of concepts, terms and their relationships.
  • Collaboration (between partners, and between partners and interested parties) is a key to success. Service means mediating between existing efforts. AOSshould facilitate communication.
  • Contact with similar initiatives.
  • Business plans vs strategic plans.
  • Intellectual property rights are an issue.
  • Pilot projects to capture interests of potential funders, as well as to facilitate advocacy to potential users of the AOS, and to inform technical development of the AOS.
  • Governance will be a critical issue to successful implementation and longterm viability.
  • Continuity and permanent availability of service is vital. Is AOSviable and sustainable?
  • Maintenance needs addressing, as does service provision.
  • Does the AOSreplace existing thesauri and other KOSs? (Users are familiar with existing KOSs, and note implications for pre-AOSbackfiles and ‘backwards compatibility’).
  • Standardized relationships and conceptual templates are required.
  • Versioning is an issue.
  • Interaction / interoperability between AOSand other ontologies.
  • Users who use ontologies have different needs from those who create ontologies, so their needs to be feedback from the former to the latter.
  • Online interaction for end user to see how search engine is working, and how terms are defined (what concepts they describe) and how they are related; cf. AOSwithout user interfaces.
  • Is ‘indexing’ of a resource necessary (in the future)? Do we need to continue indexing in the long term?
  • Multilingual alternatives. (Automatic translation a long-term objective).
  • Authority files need coordination and quality controls. Quality evaluation of KOSinputs is an issue.
  • ‘Granularity’ of applications and of (within, between) domain areas is an important consideration. Thus, there needs to be terms of appropriate specificity. Users enter at the level appropriate to them.
  • Mini- and micro-ontologies vs whole AOSontology. (N.B. terms with different meanings in different contexts (disambiguation of homonyms)).

Presentations of the AOS Users ‘Focus Group’ Workshop 2002