Difference between revisions of "SDIWG:Action Items 20081219"

From NAMIC Wiki
Jump to: navigation, search
Line 9: Line 9:
 
** Action: Ivo - weekly update of iTools already done
 
** Action: Ivo - weekly update of iTools already done
 
** Action: Beth - <strike>document the fact that HTTP will inform last date/time of biositemaps file update</strike> (done)
 
** Action: Beth - <strike>document the fact that HTTP will inform last date/time of biositemaps file update</strike> (done)
 +
** Action: Beth - registration form for adding biositemaps to registry
 
** Action: Beth - Grep-like application against all biositemaps (Use Csongor's editor in browse only for presentation)
 
** Action: Beth - Grep-like application against all biositemaps (Use Csongor's editor in browse only for presentation)
 
** Action: Csongor - browseable mode for biositemaps editor
 
** Action: Csongor - browseable mode for biositemaps editor

Revision as of 14:54, 13 January 2009

Home < SDIWG:Action Items 20081219

Go back to top level of Resourcome working group discussion pages http://na-mic.org/Wiki/index.php/SDIWG:_NCBC_Resource_Yellow_Pages_and_Software_Ontologies

Who: Natasha, Csongor, Ivo, Beth, Peter

Discussion and Action Items (2008-12-19):

  • What is minimum that is absolutely necessary? mechanism to publish: create form (auto-add to registry & email & widget for human-authentication)
    • Action: Natasha - weekly update of bioportal with latest biositemaps
    • Action: Ivo - weekly update of iTools already done
    • Action: Beth - document the fact that HTTP will inform last date/time of biositemaps file update (done)
    • Action: Beth - registration form for adding biositemaps to registry
    • Action: Beth - Grep-like application against all biositemaps (Use Csongor's editor in browse only for presentation)
    • Action: Csongor - browseable mode for biositemaps editor
  • Do we have a good information model? Do we have good documentation?
    • Action: Someone (Natasha?) to email Joy at Stanford to review biositemap web site after above minimum requirements are met (e.g. here is where your current biositemap, how to view, update, etc.)
  • Note: Csongor back on January 8th
  • Note: Next meeting on 1-16-2008 (Beth to email reminder in January)

Outstanding action items:

  • Beth & Csongor: work on merging apis (complimentary functionality) upon his return from Australia (week of Dec. 15)
    • Csongor & I need to talk about this, but given all the editor work that is on Csongor's plate, I believe Michigan should be able to do this work
  • Csongor: Update Biositemaps Editor to allow invalid classes
    • Csongor, can this be done by end of January?
  • Beth & Peter: follow up with NCBC centers to publish & update biositemaps (note I2B2 & CCB use deprecated classes that need to be updated)
    • wait on this until other outstanding issues are completed
    • comment out deprecated classes for now (done)
  • Ivo: Update iTools application to consume new biositemaps RDF files via RDF-to-XML web service
    • Ivo/Natasha: Outstanding issues listed in followup email
  • There are problems with the database or bioportal that need to be resolved in order to expose NCBC resources on bioportal
    • Natasha: early January release should fix this
  • Beth: will clarify who will develop biositemaps search application following CTSA call regarding BRO/IM harmonizing
    • While we didn't get a chance to discuss this on the CTSA call, Michigan is willing to work on this with a target date early in 2009 (an exact date wouldn't be available until we can get our team to meet after the holidays).
  • Modify Biositemaps Editor to support multiple resource types
    • Csongor: to be done early next year (January 2009)
  • Modify Biositemaps Editor to support harmonized CTSA biositemaps information model:
    • Csongor: update editor
    • Question: Can Harpreet to write converter?
  • The expanded/harmonized biositemap has 25 possible properties which should be reviewed/trimmed down if possible
    • Byline will be dropped
    • Language and platform kept as optional
    • biositemap_author kept as optional (note that CTSA wants this not displayed in the editor -- they see it as a disincentive)
  • A significant outcome of the harmonizing call was the much broader definition of what is a Biomedical Resource that CTSA uses. Nancy and Harpreet were planning on following up with their proposed additions to the BRO first week of January

Biositemaps Web-Services Specifications

I. Biomedical Resource Ontology (BRO) ontology

  • (http://bioportal.bioontology.org/virtual/1104). The following methods/functions will be valuable:
    • getBRO(): returns an XML with the complete current BRO hierarchy (starts with BRO root node)
    • getParents(BRONode): returns an XML with the meta-data of all the parents (in the BRO hierarchy), given BRONode. Most of the time there will be 1 parent, but there may be many
    • getChildren(BRONode): returns an XML with the meta-data of all the children (in the BRO hierarchy), given BRONode
    • getPartialBRO(BRONode): returns an XML with the meta-data of the BRO sub-hierarchy starting with BRONode
    • getSiblings(BRONode): returns an XML with the meta-data of all the siblings (in the BRO hierarchy) of the given BRONode (same hierarchy level)

II. Information Model (IM)

  • http://www.ncbcs.org/biositemaps/formatDescription.html. The following methods/functions will be valuable:
    • getBiositemapsIM(): returns an XML with the meta-data of all the required/formal IM fields, their properties and descriptions. Like in: http://www.ncbcs.org/biositemaps/formatDescription.html
    • getBiositemapsIM_Property(int): returns an XML with the property-name of the IM field index by "int".
    • getBiositemapsIM_Description(int): returns an XML with the description of the provided IM field index by "int"
    • getBiositemapsIM_Description(property): returns an XML with the description of the provided IM property-name
    • getBiositemapsIM_Optional(property): returns an XML with the triples (name, property, value) of all non-standard, optional and non-core IM fields.

III. General Biositemaps.RDF web-service that provide not only the standard/required/IM meta-data, but any project/center/field- specific meta-data provided by the Biositemap creator/curator

That is, we can have a center that has created a new Biositemap.RDF object, which contains the triple (name=NewField; property=NewProperty; value=NewValue). Suppose, "NewField" is *not* in the Biositemaps IM. We still need to provide services for people/ tools to retrieve this triple in XML, just like we allow retrieval of IM fields. This may be relatively easy, once we have the first two extensions (I. and II.).