Difference between revisions of "Meeting Minutes 20080919 Lysters8"
From NAMIC Wiki
m |
m |
||
Line 35: | Line 35: | ||
===6. Should the Biositemaps white paper be updated? It still refers to an xml format=== | ===6. Should the Biositemaps white paper be updated? It still refers to an xml format=== | ||
− | * We need to make a collective decision if we tightly couple Biositemaps and BRO2.1 (and subsequent versions) Do these become one-and-the-same? I recommend we keep these concepts separate, synergistic and interoperable -- according with the general philosophy that compartmentalized resources, where each component can easily and efficiently be swapped with another (functionally equivalent) component, typically have broader appeal, longer shelf-life and function better. | + | * We need to make a collective decision if we tightly couple Biositemaps and BRO2.1 (and subsequent versions). Do these become one-and-the-same? I recommend we keep these concepts separate, synergistic and interoperable -- according with the general philosophy that compartmentalized resources, where each component can easily and efficiently be swapped with another (functionally equivalent) component, typically have broader appeal, longer shelf-life and function better. |
* Biositemaps make more sense as a concept and an infrastructure, rather than one specific implementation. If BRO and Biositemaps are "conceptually merged" and the "tiger team" decides to revise the (old) Biositemaps white-paper, the (new) manuscript title should be specific and include "RDF-based Biositemaps using Biomedical Resourceome Ontology". Again, I personally favor the distributed & decentralized approach to the (general) Biositemaps framework. If this is the approach the team decides to take, we may need two white-papers that emphasize "interoperability" rather than "standardization"! | * Biositemaps make more sense as a concept and an infrastructure, rather than one specific implementation. If BRO and Biositemaps are "conceptually merged" and the "tiger team" decides to revise the (old) Biositemaps white-paper, the (new) manuscript title should be specific and include "RDF-based Biositemaps using Biomedical Resourceome Ontology". Again, I personally favor the distributed & decentralized approach to the (general) Biositemaps framework. If this is the approach the team decides to take, we may need two white-papers that emphasize "interoperability" rather than "standardization"! |
Latest revision as of 18:25, 19 September 2008
Home < Meeting Minutes 20080919 Lysters8Back to the 2008/09/19 Meeting Page
Contents
- 1 Peter Lysters Top 8 Action Items (August 2008)
- 1.1 1. Debrief meeting by tiger team
- 1.2 2. What remains to be done with the Biositemaps and BRO2.1 definition prior to their release?
- 1.3 3. Consumer/Authoring Tools for Biositemaps and BRO
- 1.4 4. We should get members from each of the centers on the tiger team
- 1.5 5. What remains to be done with the Biositemaps website and/or dissemination prior to release?
- 1.6 6. Should the Biositemaps white paper be updated? It still refers to an xml format
- 1.7 7. How/when to approach other groups regarding harmonization (yes, that is the first time I have put that word in writing) and adoption of Biositemaps/BRO 1.0?
- 1.8 8. Next Steps beyond 2.1?
Peter Lysters Top 8 Action Items (August 2008)
The following 8 action items are derivatives of the NCBC AHM and are required before a formal release of Biositemaps/BRO 1.0.
1. Debrief meeting by tiger team
2. What remains to be done with the Biositemaps and BRO2.1 definition prior to their release?
3. Consumer/Authoring Tools for Biositemaps and BRO
This is what is needed is a light-weight, agile, robust and functional library to make the new RDF-based Biositemaps usable by other external resources (including, but not limited to iTools):
- Consumption/Interpretation of biositemaps corpus
- General User
- Viewers (Browser, graphical, customized) (e.g., iTools)
- Individual resource Explorers
- Compendium of Resources
- Mining, comparison, discovery of CompBio Resources
- Viewers (Browser, graphical, customized) (e.g., iTools)
- Expert User (e.g., iTools)
- Reader/Parsers
- API
- General User
- Authoring/Generation of biositemaps and BRO
- General User
- Entry/Update Forms (Browser, graphical, customized)
- Individual resource Explorers
- Expert User
- Writer/Parsers/Crawlers/Finders
- API
- Resourceome Integration/Interoperability
- General User
- Timeline for BioPortal to allow browsing/searching Biositemap tools tagged/identified with BRO entries
4. We should get members from each of the centers on the tiger team
5. What remains to be done with the Biositemaps website and/or dissemination prior to release?
6. Should the Biositemaps white paper be updated? It still refers to an xml format
- We need to make a collective decision if we tightly couple Biositemaps and BRO2.1 (and subsequent versions). Do these become one-and-the-same? I recommend we keep these concepts separate, synergistic and interoperable -- according with the general philosophy that compartmentalized resources, where each component can easily and efficiently be swapped with another (functionally equivalent) component, typically have broader appeal, longer shelf-life and function better.
- Biositemaps make more sense as a concept and an infrastructure, rather than one specific implementation. If BRO and Biositemaps are "conceptually merged" and the "tiger team" decides to revise the (old) Biositemaps white-paper, the (new) manuscript title should be specific and include "RDF-based Biositemaps using Biomedical Resourceome Ontology". Again, I personally favor the distributed & decentralized approach to the (general) Biositemaps framework. If this is the approach the team decides to take, we may need two white-papers that emphasize "interoperability" rather than "standardization"!
7. How/when to approach other groups regarding harmonization (yes, that is the first time I have put that word in writing) and adoption of Biositemaps/BRO 1.0?
- This depends on the answer of the Biositemaps/RDF-BRO synergies questions above. I would not widely announce anything that is not 98% functional. We are certainly close, though.