View source for SDI: Minutes of December16 New Centers meeting in Bethesda

'''Minutes to open SDIWG discussion 20051216'''

This is the minutes of the SDIWG discussion on the afternoon of the New Centers Roadmap National Centers for Biomedical Computing (NCBC) in Bethesda MD--[[SDI:_Agenda_for_December16_New_Centers_meeting_in_Bethesda|here is the agenda and full details about the meeting.]]

Lyster: Gives an [[Media:SDI_New_NCBC_Dec16_2005_1.ppt| update]] of what has happened in the last year. Summary:

The Charter of SDIWG is: The RFA states the goal of creating “the networked national effort to build the computational infrastructure for biomedical computing for the nation”. [[Here_is_a_link_to_relevant_text_in_the_Announcement_RFA-RM-04-003|Here is a link to relevant text in the Announcement RFA-RM-04-003]]. In furthering this, the goals of the SDIWG in concert with the Project Team and Centers staff are:

1. To advance the domain sciences, and promote software interoperability and data exchange.

2. To capture the collective knowledge of software engineering and practices among the Centers and publish this knowledge widely.

Since the NCBC program started in the Fall of 2004 we have had a series of monthly tcons, summarized in the minutes pages on this wiki and in the [[SDIWG:Software_Engineering_Body_of_Knowledge_Across_NCBC_Biocomputing_Centers|ongoing thread]].

The SDIWG considered embarking interoperability demonstrations among the Centers (as appropriate according to the various domain areas), and although that is an important and useful goal, it is currently on the back burner. There is a sense in which the Centers need to Operate before they Interoperate. The SDIWG also considered its role in software development, and the effort may be compartmentalized (in order of increasing difficulty and sophistication) as (i) yellow pages, (ii) knowledge environment, and (iii) collaborative software development environment. All three should contribute to an environment that is useful to both developers and users. Finally, we discussed how the SDIWG proposed to develop an ontology that may be used to categorize software. This could be used, say, as a basis of concept-based query of our tools and thus enable better access for outside users. It could also be useful for developers. In the best-case scenario, the NCBCs may generate critical mass (‘tipping point’) and galvanize the biomedical computing community. Members of the SDIWG have suggested a process for doing this, using a combination of tcons to resolve the various hierarchies among the seven Centers and OWL technology. The ongoing activity can be viewed at the [[SDIWG:NCBC_Software_Classification|software classification-ontology page on this wiki]].

There have been a number of interesting email threads on how to proceed, and these will be taken up in future meetings of the SDIWG (Third Friday of each month at 2:30 PM Eastern Time, please contact Peter Lyster if you'd like to be involved lysterp@mail.nih.gov). As a strawman, one suggestion from Daniel Rubin (to be taken up at the SDIWG) for how to proceed is:

1) Identify one person at each NCBC who is interested in the issue of categorizing their software and who is willing to work with us in incorporating their taxonomy into Ivo Dinov's "top level" ontology (this is the one that has been incoporated in protege [http://bioontology.org/ontologies/SoftwareOntology/ [1]]). Each such person will look at this ontology and either (1) suggest changes needed in order to incorporate their ontology under it, or (2) incorporate it directly.

2) After everyone's software has been incorporated into one ontology, then we can look at developing a set of attributes to describe all software programs.

3) Finally, each NCBC creates an instance in the ontology to describe each of their software programs. These descriptions can be stored in OWL and hosted at the various NCBCs and updated as needed. They will also form the basis for a consistent description of all software in the NCBCs, and will facilitate search by users seeking to find software according to their needs.

Athey: [New subject] they already have collaborative software development environment. Are we talking about doing it between all Centers? Each Centers is already a collaboration. Is there a need for collaboration among between Centers?

Lyster: Early on the SDIWG did not think a monolithic environment (software development, databases, standards,…) is the right approach. Perhaps ‘federation’ is a better principle, such as espoused by the [[SDIWG:Software_Engineering_Body_of_Knowledge_Across_NCBC_Biocomputing_Centers|at the regular meeting minutes and ongoing discussion among the Centers]]. We should do a better job of enumerating these and reporting on progress.

States: Should we revisit this issue in the light of the new Centers? I.e., second set of Centers may not have quickly dismissed centralization. The Centers need to leverage.

Lyster: What has happened in the past is not fixed in stone—we can reevaluate future directions.

Covitz: Centers would/should have software environment available to other centers. Every center should come up with strategy for outside collaborators to come in.

Lyster: Someone suggested we (meet with all Centers) to see if we can adopt common set of ontologies. NOTE: it is clear that we are going to research a common [[SDIWG:NCBC_Software_Classification|software classification-ontology]], but it is not clear how to proceed (across Centers) on the issue of biomedical ontologies in general. This should be a fruitful area for future discussion.

Califano: We are only two years in. Expecting to use same syntax may not get it done in time.

Musen: One of the goals is to make software available to the community.

Lyster: The discussion often moves between priorities, and there is some uncertainty among the Centers that needs to be resolved: do we want to be more user- or developer friendly? Are we talking about ontologies to categorize software or biomedical ontologies in general?

Athey: Focus on enhancing DBPs. Need to be opportunistic to work in collaborative model.

Musen: Need to clarify what we are trying to share and why? Enumerate goals, who are we trying to please (users/developers)? He uses web-based portal. Is not sure how much will be useful outside of his Center. Need to be enumerable. Don’t build shrink-wrapped software. Some of our best software may be sharable (in the sense of share commit privileges) but not used by multiple Centers. It would be useful to catalogue.

Whitmarsh: Discusses goals of NCBCs.

Califano: Need to decide what we want to do ourselves. Think what caBIG is doing—use bronze, silver, level to enforce interoperability. There are in effect eight Centers, if you include NCBI. Suggest an extension of the committee not just to deal with software development practices. Are there gaps?

Musen: Clarify what are the use cases for people who want to access inventory. Enumerate use cases (Note taker: are we talking about DBPs, or tools, or …?)

Athey: We are software developers. Build it and they come was an approach at one time. There is a realization that weed to develop user communities (Note taker: I’m not sure if I got that right?). Who are customers?

Skinner: What is unique about here that’s more than separate efforts. The final goal of the NCBC as described in the [[Media:NCBC_Z-Gram.ppt| Zerhouni-gram matrix]] deals with infrastructure.

Skinner challenges us: What would be the three essential components of successful NCBC effort after 10 years?

Musen: There may be conflicting goals—each of the Centers has a different tack. Seeking users. What worries him is … web services is a catalogue… would you want to make it available? (Note taker: I’m not sure if I got this right?)

Ackerman: ITK comes as a bolus. That is the design, i.e., a rational approach to the user-developer was used.

Califano: caBIG web services come as individual components.

Bliton: Large scale value added.

Califano: Get’s a lot of queries. DBPs become examples of solutions that can be adopted. Why do DREAM (Note taker: not sure if I got that right) reverse engineering? Problem is that they develop a program that is agnostic wrt performance. Or no clue of techniques. Perhaps we (NCBCs) should provide guidance and cycles.

Bean: Rather than just focusing on ontologies perhaps we need index of descriptors. Highly dynamic multiple descriptors (Note taker: I’m not sure if I got that right?).

Musen: Suggest open directory project. People with interest in tools. Enumerate.

Lyster: This is very much on the same line as the recent directions of the SDIWG, i.e., ontology for software tools and their potential uses (i) for concept-based queries (i.e., useful for users); and (ii) potentially useful for developers.

Skinner: Challenge—what form would networked NCBC take, and what would they achieve?

Lyster’s quick response to Skinner’s challenge—

We want to achieve:

* As a result of the critical mass of the Centers, we expect to develop tools that enable advances and discoveries in the domain sciences
* We expect to generate knowledge that enables biomedical computational developers to improve their process
* We expect to improve the user access to tools

Possible things to do:

* Adopt a common set of ontologies (not just to categories tools but to do the science)? How different is this from BISON?
* Do a gap analysis?
* Explore process similar to the caBIG compatibility guidelines?