Software and Utilities group summary: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
Line 33: Line 33:
;What criteria are used to set priorities?
;What criteria are used to set priorities?
:Priorities for each activity will be set in discussion with group members and PIs. Priorities for individual tools (e.g. OBO-Edit and AmiGO) will be set by the WG members, although the Software group and Pis will set long-term strategic priorities.
:Priorities for each activity will be set in discussion with group members and PIs. Priorities for individual tools (e.g. OBO-Edit and AmiGO) will be set by the WG members, although the Software group and Pis will set long-term strategic priorities.
=== Roadmaps ===
#[[Database_Roadmap]]
#[[Logical_Definitions_Roadmap]]


==Reports==
==Reports==

Revision as of 20:17, 15 January 2007

GO Software Working Group Report 26nd April 2006

Purpose

What is the group’s purpose?
The purpose of the Software group is to support both the GOC and the user community with technical, software, bioinformatics and computer-science related matters. In addition, this group will help drive the GOC through the research and provision of new computational technologies and methodologies relating to ontologies and ontology-based data analysis.

This group is responsible for creating, clarifying and extending the common model that underpins all of GO

What makes this group necessary and unique?
Ontology development tools are necessary for the Ont-Dev group to perform its function. In addition, the annotation group and wider community need means of exploring and utilizing GO and existing annotations. This group complements all the other groups.
What is the lifespan?
The Software group will endure for the duration of the GO project.

Group Leader

Chris Mungall (Lawrence Berkeley National Laboratory)

Activities

What are the key deliverables of this group?
As the scope of this group and other groups become better defined, the key deliverables will need to be further discussed among the PIs and other GO managers.

Initially, the immediate deliverables could include the iterated releases of the following pieces of software:

  1. Curation tools, both for ontology editing and ontology-based annotation for all users
  2. Ontology browsing and analysis interfaces and data dissemination for all users
  3. Software and analysis tools and application programmer libraries intended for bioinformatics and computational users
  4. Software artifacts for ensuring a consistent, stable formal underpinning and common model for all of GO; this includes database schemas, object models and file format specifications, as well as the tools for converting between them. Clear and unambiguous documentation explaining this model, aimed at both biologists and computer scientists
What criteria are used to set priorities?
Priorities for each activity will be set in discussion with group members and PIs. Priorities for individual tools (e.g. OBO-Edit and AmiGO) will be set by the WG members, although the Software group and Pis will set long-term strategic priorities.

Roadmaps

  1. Database_Roadmap
  2. Logical_Definitions_Roadmap

Reports

  1. Software_and_Utilities_Report_2006

Members

Members will be added as the Berkeley group hires.

  • John-Day Richter – OBO-Edit development
  • ShengQiang Shu – AmiGO development (part time )
  • Seth Carbon - AmiGO development
  • Karen Eilbeck – SO related software
  • Ben Hitz

Open question: How do the SGD production developers fit in?

Meeting calendar

Metrics of success

What are the group's objectives?
  1. Provide the GO Ontology Development group with the tools and support it requires in order to do its job, and to use these tools to extend, check and enhance the ontology as required and as detailed in specific aim 1
  2. Develop the formal framework and associated software and information artifacts which underpin both ontology content and annotation; for example, database schemas
  3. Work with the Reference Genome group to provide annotation tools and analyses and metrics for evaluating and enhancing the quality of reference annotations
  4. Provide the GO community with the interfaces and resources required for effective use of the GO and the annotations to the GO. This includes everyone ranging from wet-bench biologists and biomedical researchers through bioinformaticians and computer scientists
  5. Work with the outreach group to ensure the above is adequately documented and accessible by the wider community
How is the group success evaluated?
  1. By proxy with the Ont-Dev groups metrics of success, and determining the extent to which the Software group contributed to successful completion of that groups objectives
  2. By informal feedback from within the consortium, and by peer review from experts in the field
  3. By proxy
  4. Crude metrics could include the number of downloads of software tools and resources made available by the group, as well as usages patterns of public user interfaces like AmiGO. Another crude metric is response time to software bug reports and tracker items. Better metrics could involve better mechanisms to get feedback from tool users, and questionnaires on mail lists.
  5. From feedback


Linkages

  • Ontology Development group
    • To set priorities for the development of tools and enhancements to support aim 1. To help create and clarify the formal underpinning of GO
  • OBO-Edit working group
    • Ensure that OBO-Edit meets both the needs of Ont-Dev, annotators and the wider community, and to ensure that the direction of OBO-Edit is in compliance with wider ontology and software community standards where appropriate. To set long term strategic goals and priorities
  • AmiGO working group
    • Ensure that OBO-Edit meets the needs of the GO community and the annotators. To set long term strategic goals and priorities
  • Annotation-Ontology Group
    • To define and clarify the model underpinning GO particularly with respect to how the annotation model connects to the ontology model
  • GO Leadership
    • Overall direction and strategy. Monthly meetings

Process

  1. What are the key decisions?
    1. How can we improve tools to benefit the user experience?
    2. How can software tools and computational advances be used to improve, enhance and extend the content of the GO; either directly or as aids to curation? How can tools be used to enhance annotation?
    3. Is the model underpinning the GO and its annotations sufficiently expressive and unambiguous to allow for effective communication of knowledge and meaningful comparisons and transfer of knowledge across genomes? Can the model be improved to better meet the needs of the consortium and the users?
    How are decisions made?
    For any decision we explore
    • What investment is required by the Software group to research, investigate, develop, test and/or deploy these?
    • What is the expected return?
    • What will the impact of deploying these be on the members of the GO consortium, the wider community (both biologist and computational users), either directly or indirectly through knock-on effects with other technology?
    After this analysis, we decide as follows:
    • For decisions in which investments are minimal and the impact is largely invisible the group will make decisions autonomously.
    • For larger investments, the PIs and possibly other appropriate consortium members will be consulted
    • For any non-minimal visible impact changes, whether positive, neutral or mixed, both PIs and appropriate groups will be consulted. The wider community may be consulted, via the approproate group (eg outreach or software working group)
    • Any long term strategic decisions are made in consultation with PIs and the consortium
    • For the purpose of decision making, the production database team at Stanford will be considered part of the software group and internal group consultations can be assumed
    In addition, we discuss bigger decisions on one of the various mail lists (go-database, gmod-ontol-sw-devel or other) and listen to feedback from non GOC developers
    What is the flow of choices?
    Decision points are identified as far in advance as possible and written up and discussed on the wiki and/or mail list and/or tracker. Individual software developers can exercise discretion and make small decisions autonomously or after consultation with appropriate software group members.
    Prototypes, mock-ups, demos or tests are written to demonstrate the impact of decisions and feasibility; this is vital in some cases to enhance communication between the software developers and biologists
    The decision is discussed and analysed as above, and the Software group lead makes the decision, deferring to PIs as appropriate


Software and Utilities group main page